UNIVERSIDAD MAYOR DE SAN ANDRÉS FACULTAD DE CIENCIAS PURAS Y NATURALES CARRERA DE INFORMÁTICA
TESIS DE GRADO
“SISTEMA DE GEORREFERENCIACIÓN DE RESTAURANTES EN LA CIUDAD DE LA PAZ MEDIANTE EL USO DE SMARTPHONES”
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA MENCIÓN: INGENIERÍA DE SISTEMAS INFORMÁTICOS
POSTULANTE : RAINER FLORES IBAÑEZ TUTOR METODOLÓGICO : LIC. JAVIER HUGO REYES PACHECO ASESOR : Ph.D. YOHONI CUENCA SARZURI
LA PAZ – BOLIVIA 2016
UNIVERSIDAD MAYOR DE SAN ANDRÉS FACULTAD DE CIENCIAS PURAS Y NATURALES CARRERA DE INFORMÁTICA
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil. b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado. c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
DEDICATORIA
Quiero dedicar este trabajo a mis padres, José y Victoria. Por su constante apoyo, que, a pesar a los diferentes obstáculos de la vida, siempre están a mi lado para darme su apoyo incondicional y en especial a mi madre por su inmenso amor y dedicación, quien me enseñó que con amor y trabajo todo se pude lograr.
“All You Need Is Love”
i
AGRADECIMIENTOS
Al llegar a esta instancia de mi vida quiero agradecer a las personas que me colaboraron para el logro de mi tesis. Los agradecimientos van destinadas a todas las personas que me orientaron con sus valiosas sugerencias, que sin ellos no hubiese sido posible su conclusión.
A mis padres que sin su apoyo incondicional sería imposible este trabajo y por inculcarme la importancia de una carrera profesional y generar el desafío personal de superar y alcanzarla
Agradecer infinitamente al Lic. Javier Hugo Reyes Pacheco y mi Tutor, al Ph.D. Yohoni Cuenca Sarzuri mi Asesor, por todo el apoyo constante a mi persona, su sabiduría y experiencia profesional, respaldándome durante la elaboración y acabado de la misma; aconsejándome con acierto, permitiéndome presentarles este trabajo.
Agradezco a mi familia Zulema, Miguel, Ivens, José, Prince, Julio, Franco, Ronald, Pedro y Miguel quienes confiaron y me apoyaron para seguir hasta el final de este proyecto.
Y por último agradezco a Patty, mi pareja de la vida.
Rainer Flores Ibañez [email protected]
ii
RESUMEN
La presente tesis de grado denominada “Sistema de Georreferenciacion de restaurantes en la ciudad de La Paz mediante el uso de smartphones” con el objetivo de localizar los distintos restaurantes distribuidos alrededor de la urbe paceña, a través de una aplicación para celulares inteligentes dando una opción de solución a la falta de un servicio que ayude a georreferenciar los distintos puntos gastronómicos de la ciudad de La Paz.
En el presente proyecto se propuso desarrollar una aplicación móvil que dé solución a los problemas que los comensales encuentran al momento de buscar información concerniente a los restaurantes en el área urbana de la ciudad de La Paz, proporcionando una asistencia segura, interactiva, pero sobre todo de fácil acceso a la información.
Esta aplicación fue encarada con el uso de servicio de georreferenciación para visualizar los geopuntos de los lugares en el mapa y almacenamiento en la nube para guardar la información de manera segura y eficaz, la cual facilita la disponibilidad de información en cualquier momento para el usuario además de ser de rápido acceso.
Finalizado el proyecto, mediante un sondeo de preguntas a usuarios que operaron con la aplicación en dos oportunidades, se obtuvo que la aplicación tuvo una aceptación favorable, el 89 % prepondero la facilidad de uso y fue destacada de mucha utilidad, aconsejable para otros usuarios y a su vez usuarios constaron el ahorro de tiempo al momento de localizar un lugar gastronómico en la urbe Paceña.
Palabras clave: Georreferenciación, Smartphone, restaurantes, Ionic, AngularJs, Html
iii
ABSTRACT
This thesis entitled " Sistema de Georreferenciacion de restaurantes en la ciudad de La Paz mediante el uso de smartphones " in order to locate the various restaurants scattered around La Paz city, through an application for smart phones giving an option solution to the lack of a service that helps georreferenciar different gastronomic points of the city of La Paz.
In this project set out to develop a mobile application that gives solution to the problems that diners are when seeking information concerning restaurants in the urban area of the city of La Paz, providing a secure, interactive support, but above all easy access to information.
This application was faced with the use of service georeferencing to display geopoints places on the map and cloud storage to store data securely and efficiently, it facilitates the availability of information at any time for the user besides being fast access.
Completion of the project through a poll questions for users who operated with the application twice, it was found that the application had a favorable acceptance, 90% prepondero usability and was featured very useful, recommended to other users and turn consisted users save time when you find a gastronomic place in La Paz city.
Keywords: Georeferencing, Smartphone, restaurants, Ionic, angularjs, Html5.
iv
ÍNDICE
CAPÍTULO I: MARCO REFERENCIAL ...... 1
1.1 INTRODUCCIÓN ...... 1 1.2 ANTECEDENTES ...... 2 1.3 PLANTEAMIENTO DEL PROBLEMA ...... 3 1.4 OBJETIVOS ...... 4 1.4.1 Objetivo general ...... 4 1.4.2 Objetivos específicos ...... 4 1.5 JUSTIFICACIÓN ...... 5 1.5.1 Justificación Social ...... 5 1.5.2 Justificación Económica ...... 5 1.5.3 Justificación Tecnológica ...... 6 1.6 ALCANCES Y LIMITES ...... 6 1.6.1 Alcances ...... 6 1.6.2 Limites ...... 6 1.7 METODOLOGÍA ...... 7 CAPÍTULO II: MARCO TEÓRICO ...... 8
2.1 INTRODUCCIÓN ...... 8 2.2 SERVICIOS DE GEORREFERENCIACIÓN ...... 8 2.3 GEOLOCALIZACIÓN EN DISPOSITIVOS MÓVILES ...... 9 2.4 TECNOLOGÍA MÓVIL ...... 10 2.4.1 Dispositivos móviles ...... 10 2.5 SISTEMA OPERATIVO MÓVIL ...... 10 2.5.1 Justificación de la selección del SO ...... 12 2.5.1.1 Aplicaciones Nativas ...... 13 2.5.1.2 Interfaz de Programación de Aplicaciones(API) ...... 14 2.5.1.3 Aplicaciones Móviles basadas en la Web ...... 16 2.5.1.4 Aplicaciones Hibridas ...... 17 2.5.2 Comparación de los distintos enfoques de aplicaciones ...... 18 2.6 SERVICIOS EN LA NUBE ...... 20 2.6.1 Base de datos en la nube ...... 21 2.6.2 Estructura de los servicios en la nube Firebase ...... 22 2.7 ENTORNO DE DESARROLLO PARA MÓVILES ...... 23 2.8 KIT DE DESARROLLO ...... 24 2.8.1 Ionic framework...... 24 2.8.1.1 Apache Cordova ...... 24 2.8.1.2 Java Script ...... 25 2.8.1.3 Angular Js ...... 26 2.8.1.3.1 El Patrón MVC ...... 27
v
2.8.1.3.2 Data binding ...... 29 2.8.1.4 HTML5 ...... 29 2.8.1.5 CSS3 ...... 30 2.9 ANÁLISIS Y DISEÑO ...... 30 2.9.1 Análisis y Diseño Orientado a Objetos(A/DOO) ...... 31 2.9.2 Lenguaje Unificado de Modelado (UML)...... 31 2.9.3 Por qué es necesario UML ...... 32 2.9.4 Aplicaciones de UML y patrones en el A/DOO ...... 32 2.9.5 Modelo Conceptual ...... 33 2.9.6 Diagrama de Casos de Uso ...... 33 2.9.7 Diagrama de Clases ...... 33 2.9.8 Programación Extrema (XP) ...... 34 2.9.9 Las Cuatro variables ...... 34 2.9.10 Los Cuatro Valores ...... 34 2.9.11 Comunicación ...... 35 2.9.12 Sencillez ...... 35 2.9.13 Retroalimentación ...... 35 2.9.14 Valentía ...... 36 2.9.11 El Proceso XP ...... 36 2.9.11.1 Fase de Exploración ...... 37 2.9.11.2 Fase de Planificación ...... 37 2.9.11.3 Fase de diseño ...... 38 2.9.11.4 Fase de Iteración ...... 39 2.9.11.5 Fase de pruebas ...... 39 2.10 CONTROLES DE SEGURIDAD IMPLEMENTADOS SEGÚN RECOMENDACIÓN DE LA OWASP ...... 40 CAPÍTULO III: MARCO APLICATIVO ...... 46
3.1 ANÁLISIS, DISEÑO Y DESARROLLO DE LA APLICACIÓN ...... 46 3.1.1 Análisis y Diseño ...... 46 3.1.1.1 Modelo Conceptual ...... 46 3.1.2 Identificación de Requerimientos ...... 47 3.1.2.1 Requerimientos Funcionales ...... 47 3.1.2.2 Requerimientos no Funcionales ...... 49 3.1.3 Catálogo de actores ...... 49 3.1.4 Paquetes ...... 51 3.1.4.1 Casos de Uso ...... 52 3.1.4.1.1 Paquete de Flujo Administración del Sistema ...... 53 3.1.4.1.2 Paquete de Flujo Restaurantes...... 53 3.1.4.1.3 Paquete de Flujo Consumidores ...... 54 3.1.4.1.4 Paquete de Seguridad...... 54 3.1.4.2 Especificación de Casos de Uso ...... 55 3.1.4.3 Diseño Navegacional ...... 61 3.1.4.4 Diseño de Interfaz Abstracta ...... 62
vi
3.1.4.5 Diagrama de Secuencia de Registro de Georreferenciación de Restaurante 63 3.1.4.6 Diagrama de Clases ...... 63 3.1.5 Desarrollo de la Aplicación ...... 64 3.1.5.1 Las Cuatro Variables ...... 65 3.1.5.2 Los cuatro valores ...... 65 3.1.5.3 Fase de Exploración ...... 66 3.1.5.3.1 Historias de usuario del módulo registro de restaurantes ...... 66 3.1.5.3.2 Historias de usuarios del módulo de usuarios registrados ...... 68 3.1.5.3.3 Historias de usuario del módulo registro de restaurante ...... 69 3.1.5.3.4 Historias de usuario del módulo georreferenciación de restaurantes .... 70 3.1.5.4 Fase de Planificación ...... 72 3.1.5.5 Fase de Iteración ...... 73 3.1.5.5.1 Primera Iteración ...... 73 3.1.5.5.2 Segunda Iteración ...... 74 3.1.5.5.3 Tercera Iteración ...... 75 3.1.5.5.4 Cuarta Iteración ...... 77 CAPÍTULO IV: RESULTADOS ...... 78
4.1 PRUEBAS DE DESARROLLO ...... 78 4.2 MÉTRICAS DE CALIDAD ...... 78 4.2.1 Funcionalidad ...... 78 4.2.2 Eficiencia ...... 82 4.2.3 Fiabilidad...... 83 4.2.4 Usabilidad ...... 83 4.2.4.1 Obtención de estadísticas en base al test de usabilidad ...... 84 4.2.4.1.1 Utilidad percibida de la aplicación ...... 84 4.2.4.1.2 Facilidad de uso de la aplicación ...... 86 4.3 CONTROLES DE SEGURIDAD IMPLEMENTACIÓN SEGÚN RECOMENDACIÓN DE LA OWASP ...... 86 4.4 COSTO DE LA APLICACIÓN ...... 89 CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES ...... 92
5.1 CONCLUSIONES ...... 92 5.2 RECOMENDACIONES ...... 93 BIBLIOGRAFÍA ...... 94
ANEXOS ...... 97
vii
ÍNDICE DE FIGURAS
Figura 2.1 Cuadro estadístico de los Sistemas Operativos en teléfonos inteligentes en todo el mundo...... 13 Figura 2.2 Comparación de los distintos enfoques Fuente: (IBM, 2012) ...... 19 Figura 2.3 Arquitectura de un servicio móvil ...... 22 Figura 2.4 Ionic Framework ...... 24 Figura 2.5 Arquitectura de un Apache Cordova ...... 25 Figura 2.6 Angular Js ...... 27 Figura 2.7 Modelo Vista Controlador...... 28 Figura 2.8 La orientación a objetos presta especial atención a la representación de los objetos ...... 31 Figura 2.9 Proceso XP Fuente: (Pressman, 2005) ...... 37 Figura 3.1 Modelo Conceptual del administrador, usuario y restaurante ...... 47 Figura 3.2 Diagrama de Actores ...... 50 Figura 3.3 “Diagrama de Paquete” ...... 52 Figura 3.4 “Paquete Administración del Sistema” ...... 53 Figura 3.5 “Paquete Restaurantes” ...... 53 Figura 3.6 “Paquete Consumidores” ...... 534 Figura 3.7 “Paquete Seguridad” ...... 54 Figura 3.8 Esquema navegacional de la aplicación ...... 61 Figura 3.9 Diagrama de interfaz abstracta ...... 62 Figura 3.10 Diagrama de Secuencia de georreferenciación de restaurantes ...... 53 Figura 3.11 “Diagrama de Clases del Sistema” ...... 53 Figura 3.12 Diagrama de clases, información de restaurantes registrados ...... 53 Figura 3.13 Interfaz de lista de restaurantes y detalle de restaurante ...... 74 Figura 3.14 Diagrama de clases, categorías de restaurantes registrados ...... 74 Figura 3.15 Interfaz de Categorías ...... 753 Figura 3.16 Diagrama de clases, registro de opiniones ...... 753 Figura 3.17 Interfaz de la lista de Opiniones e Interfaz de Registro de Opinión del Restaurante ...... 76 Figura 3.18 Interfaz de registro de usuario Restaurante ...... 76 Figura 3.19 Interfaz, mostrar ubicación del Restaurante...... 77 Figura 4.1 Cuadros estadísticos según encuesta de usabilidad percibida de la aplicación . 853 Figura 4.2 Cuadros estadísticos según facilidad de uso de la aplicación ...... 86
viii
ÍNDICE DE TABLAS
Tabla 2.1 Información de SO Android ...... 11 Tabla 2.2 Información de SO iOS...... 12 Tabla 2.3 Interfaces de programación de aplicaciones (API) de los Sistemas Operativos en teléfonos inteligentes ...... 15 Tabla 2.4 Características de aplicaciones móviles basadas en la Web ...... 16 Tabla 2.5 Comparación de los distintos enfoques de aplicación móviles ...... 20 Tabla 3.1 Descripción de Requerimientos Funcionales ...... 248 Tabla 3.2 Descripción de Requerimientos No Funcionales ...... 249 Tabla 3.3 Roles de actores del Sistema...... 50 Tabla 3.4 Especificación del caso de uso Consultar Restaurantes ...... 55 Tabla 3.5 Especificación del caso de uso Opinión al Restaurante ...... 56 Tabla 3.6 Especificación del caso de uso Enviar Solicitud de Nuevo Restaurante...... 58 Tabla 3.7 Especificación del caso de uso Administrar Información del Restaurante ...... 60 Tabla 3.8 Las cuatro variables de XP ...... 65 Tabla 3.9 Los cuatro valores de XP ...... 65 Tabla 3.10 Historia de usuario, mostrar información de Restaurantes...... 66 Tabla 3.11 Tarea, diseñar la estructura de datos para mostrar la información de Restaurantes ...... 66 Tabla 3.12 Tarea, interfaz de salida, para mostrar la información de Restaurantes ...... 66 Tabla 3.13 Historia de usuario, mostrar categoría de Restaurante ...... 67 Tabla 3.14 Tarea, Diseñar la estructura de datos para mostrar la información de categorías de restaurantes ...... 67 Tabla 3.15 Tarea, diseñar la estructura de datos para mostrar categorías de Restaurantes 68 Tabla 3.16 Historia de usuario, mostrar opiniones de los comensales de los Restaurantes 68 Tabla 3.17 Tarea, Crear estructura de datos para almacenar opinión del usuario del restaurante ...... 68 Tabla 3.18 Tarea, Crear Interfaz para registro opinión del usuario al restaurante ...... 69 Tabla 3.19 Tarea, Crear Interfaz para mostrar opiniones de los usuarios de los restaurantes ...... 69 Tabla 3.20 Historia de usuario, mostrar ubicación de los Restaurante...... 69 Tabla 3.21 Tarea, Diseñar la estructura de datos para el registro de restaurante ...... 70 Tabla 3.22 Tarea, Crear interfaz para registrar a restaurante ...... 70 Tabla 3.23 Historia de usuario, mostrar ubicación de los Restaurantes ...... 70 Tabla 3.24 Tarea, Diseñar la estructura de datos para mostrar ubicación de restaurantes georreferenciados...... 71 Tabla 3.25 Tarea, Crear interfaz para mostrar ubicación de los restaurantes georreferenciados...... 71 Tabla 3.26 Planificación en detalle de las historias de usuario ...... 73 Tabla 4.1 Caso de prueba...... 78 Tabla 4.2 Requerimientos funcionales ...... 79 Tabla 4.3 Requerimientos no funcionales ...... 80 Tabla 4.4 Historias de usuario ...... 80 Tabla 4.5 Factores de eficiencia...... 83
ix
Tabla 4.6 Cuestionario de presupuestos para ajustes de costos para aplicaciones móviles 90 Tabla 4.7 Costos según respuestas del cuestionario de presupuestos...... 90
x
CAPÍTULO I: MARCO REFERENCIAL
1.1 Introducción
En el actual contexto boliviano, la gastronomía boliviana es un mercado en constante movimiento tanto de alzas como de bajas. Esto quiere decir, que, así como se van formando nuevos negocios de restaurantes, también van desapareciendo otros.
Asimismo, algunos de estos permiten agilizar su ubicación a través de portales web, de tal forma que facilita esta actividad para los consumidores.
Frente a este contexto, aparece el problema de la dificultad de la ubicación de restaurantes. Por un lado, la distribución de portales web a lo largo de Internet, desemboca en una falta de centralización, lo cual no permite a los consumidores ubicar fácilmente un restaurante que se acomode a sus necesidades. Por otro lado, no todos los restaurantes cuentan con un portal web propio, lo cual genera una falta de medios de comunicación entre los restaurantes y clientes.
Por esta razón la aplicación móvil de georreferenciación, brindará una propuesta de solución tanto al problema de descentralización de los restaurantes como a la falta de medios de comunicación entre restaurantes y consumidores. Según encuestas realizadas la mayoría de las personas prefieren tener ese tipo de información en las tecnologías disponibles y de fácil acceso como la utilización de un Smartphone como dispositivo GPS.1
Para desarrollar esta solución se abarcará el análisis, diseño e implementación de un sistema de información en base a metodologías y procedimientos de ingeniería de software.
1 El sistema de posicionamiento global (GPS) es un sistema que permite determinar en toda la Tierra la posición de un objeto (una persona, un vehículo) con una precisión de hasta centímetros (si se utiliza GPS diferencial), aunque lo habitual son unos pocos metros de precisión.
1
1.2 Antecedentes
Los diferentes servicios de georreferenciación han ido creciendo en los últimos años, tales propuestas están orientadas a mejorar los tiempos de respuesta ante la búsqueda de lugares georreferenciados e incrementar la satisfacción de los usuarios. Por ello muchas empresas se dedican a desarrollar herramientas que nos ayuden en la vida cotidiana, los cuales se tomaron en cuenta como referencia los siguientes servicios y proyectos:
Google Maps Su servicio es usado por la mayoría de las personas, ya que se tiene información de todo el mundo para poder consultarla, sin embargo, esta información es imprecisa, tiene retrasos de minutos al visualizar los mapas en computadores antiguos y dependiendo de la conexión de banda ancha que tenga el equipo (Duclos, 2010).
Google Maps es el SIG más utilizado por los anteriores servicios ya mencionados debido a su facilidad de uso, documentación y soporte, pero ahora con la salida de los mapas colaborativos Open Street Maps que cuentan con mayor precisión, documentación pero aún en fase de desarrollo, es por eso que varias empresas van colaborando al proyecto Open Street Maps como por ejemplo: Apple, Microsoft(Mapas Bing), Yahoo (Mapas yahoo), foursquare que recientemente cambio de Google Maps a OpenStreetMaps en su versión pc ya que su versión para móviles aún sigue usando Google Maps.
Boliviaentusmanos Guía de Restaurantes Es un portal web con información comercial, empresarial, turística y cultural de Bolivia donde se encuentra productos y servicios en Bolivia; a través de cientos de consultas al Directorio Empresarial de Amarillas, usuarios provenientes de Bolivia y el mundo llegan a conectarse con las empresas anunciadoras (http://www.boliviaentusmanos.com/restaurantes- gastronomia/).
2
Georreferenciación de la actividad comercial grado, hace referencia a un en la ciudad de La Paz Esta tesis describe el servicio web y aplicación móvil de georreferenciación enfocada específicamente a negocios de la actividad comercial en la ciudad de La Paz, que cuenta con información detallada y actualizada. (Quispe, 2012).
1.3 Planteamiento del Problema A continuación, se dará enfoque a puntos considerados como problemáticos que se encuentran actualmente en la ciudad de La Paz, en referencia a la localización de restaurantes.
Los servicios como Google Maps en la actualidad tienen una lentitud en el proceso de registro y verificación de un nuevo sitio, con una demora aproximada de 1 mes. El tiempo de verificación de la adición de un lugar nuevo es de 3 semanas, más un lapso de tiempo de 1 mes hasta la publicación del sitio georreferenciado, provocando la desactualización de su información.
Cuando una persona interesada a degustar en un restaurant, pide información a la población en general, que debido a la falta de señalización en algunas calles y avenidas dificulta su localización.
Los sitios o portales web no proporcionan una información específica de restaurantes, como ser: especialidad gastronómica, georreferenciación del lugar de ubicación y horarios de atención, lo cual ocasiona una búsqueda ineficiente y tediosa por internet. Por otra parte, la existencia de información innecesaria en estos portales como: propagandas de empresas, entre otros, provoca pérdida de tiempo al gestionar la misma.
3
Un visitante en la ciudad de La Paz, requiere una asistencia de información más precisa de los lugares gastronómicos a visitar, por ello desean tener por comodidad información accesible de los restaurantes de la ciudad.
1.4 Objetivos 1.4.1 Objetivo general
Desarrollar una aplicación móvil para la georreferenciación de restaurantes, que permita proporcionar información confiable y oportuna referente a los lugares gastronómicos en la ciudad de La Paz.
1.4.2 Objetivos específicos
Diseñar e Implementar el módulo de georreferenciación de lugares gastronómicos de la ciudad de La Paz, para proporcionar a las personas un acceso fácil, interactivo y puntual de cada uno de ellos.
Elegir una óptima herramienta tecnológica existente para una ubicación geográfica exacta y precisa.
Desarrollar un mecanismo que permita mostrar los restaurantes de forma ordenada en base a la distancia con respecto a los usuarios, para que así el comensal tenga un criterio más con el cual decidir qué restaurante se ajusta mejor a sus necesidades.
Evaluar el rendimiento del prototipo y comprobar su eficiencia.
4
1.5 Justificación 1.5.1 Justificación Social
La aplicación a desarrollar ofrecerá grandes ventajas a la población en general, que quieran localizar de manera fácil, rápida, didáctica y precisa los diferentes centros gastronómicos de la ciudad de La Paz. Ya que se contará con una interfaz amigable, con información detallada y actualizada. Y al mismo tiempo obtener opiniones de los lugares gastronómicos más frecuentados y de interés por los comensales y medir el nivel de influencia que se tuvo en los usuarios con esta aplicación.
1.5.2 Justificación Económica
Uno de los fenómenos más importantes de la última década en términos económicos es la explosión del consumo. La gente tiene una mayor capacidad de compra, hecho que ha activado la demanda interna. Tal vez el fenómeno que mejor retrata este periodo de bonanza prestada es el crecimiento de las ventas de los supermercados y de los restaurantes.
Las cifras de las ventas de los restaurantes y supermercados son impresionantes, en 2005 estos recintos vendían 67 millones de dólares, nueve años después facturan 1.129 millones según el Ministerio de Economía. El documento revela que los establecimientos de servicios de comida obtuvieron ingresos, en 2014, de 635 millones de dólares, un 21,4% más que en 2013. El crecimiento en los beneficios de este sector de 2005 a 2014 fue de 853% (Razón, 2014).
Con estas referencias se puede afirmar que mientras más actividad de consumo gastronómico, también habrá actividad económica debido al fenómeno consumista que vive el país, por eso la tecnología e innovación pueden contribuir significativamente al desarrollo y mantenimiento de un sector gastronómico para ser más competitivo, y mejorando su sostenibilidad desde el punto de vista económico.
5
1.5.3 Justificación Tecnológica
Con la tecnología que se encuentra disponible en nuestro medio como ser los teléfonos inteligentes conocidos también como Smartphones y el acceso a internet, es factible el desarrollo de aplicaciones tecnológicas como la georreferenciación y la realidad aumentada, que favorezcan a distintas áreas de nuestra sociedad, pero en especial a la actividad gastronómica en el país.
1.6 Alcances y Limites 1.6.1 Alcances
Se tendrán los siguientes alcances:
La aplicación ayudará a encontrar y visualizar en el mapa un lugar específico de interés, y al mismo tiempo ver la información general correspondiente (no indicará rutas de llegada).
La aplicación no solo brindará información de lugares gastronómicos de la ciudad, sino también proporcionará información detallada de las especialidades culinarias de cada lugar y brindará recomendaciones a los comensales.
La aplicación contendrá registros estadísticos de restaurants más concurridos por los comensales, donde cada usuario podrá visualizar la cifra en su perfil.
1.6.2 Limites
Se necesita conexión a internet y que el equipo cuente con GPS.
6
La aplicación ayudara a encontrar y visualizar en el mapa un lugar específico de interés, y al mismo tiempo ver la información general correspondiente, no indicara rutas de llegada.
La información disponible de lugares gastronómicos solo considerara el radio urbano de la ciudad de La Paz. Por ello en el desarrollo de este proyecto se hará énfasis en algunos sitios más concurridos por la población paceña.
1.7 Metodología
El desarrollo de la investigación del presente proyecto se realizó mediante el enfoque sistémico. Se aplicó la metodología ágil extreme Programming (XP) para el desarrollo de la aplicación y se realizó un análisis y diseño orientado a objetos (ADOO) con ayuda de herramientas como el lenguaje unificado de desarrollo (UML).
7
CAPÍTULO II: MARCO TEÓRICO
2.1 Introducción
En la actualidad no existe una definición correcta para los términos de geolocalización y georreferenciación, debido a esto existe aportes de varias instituciones y personas que han tratado de determinar la diferencia entre estas dos palabras y son en realidad neologismos de la palabra inglesa Geolocation , cuya definición traducida es: “El proceso o la técnica de identificar la localización geográfica de una persona o dispositivo mediante el uso de información digital procesada vía internet” (Oxford Dictionaries, 2013).
En cuanto a la definición de georreferenciación, se puede definir de esta manera: es el posicionamiento con el que se define la localización de un objeto espacial (representado mediante punto, vector, área, volumen) en un sistema de coordenadas y datos determinado. Este proceso es utilizado frecuentemente en los Sistemas de Información Geográfica2 (SIG) (Berry, 1996)
2.2 Servicios de georreferenciación
Actualmente existen varias instituciones las cuales ofrecen georreferenciación a nivel mundial, estos servicios se describen a continuación:
Google Maps
2 SIG es un conjunto de herramientas que integra y relaciona diversos componentes (usuarios, hardware, software, procesos) que permiten la organización, almacenamiento, manipulación, análisis y modelización de grandes cantidades de datos procedentes del mundo real que están vinculados a una referencia espacial, facilitando la incorporación de aspectos sociales-culturales, económicos y ambientales que conducen a la toma de decisiones de una manera más eficaz.
8
Es un servidor de aplicaciones de mapas en la web que pertenece a Google. Ofrece imágenes de mapas desplazables, así como fotografías por satélite del mundo e incluso la ruta entre diferentes ubicaciones o imágenes a pie de calle Google Street View (Google, 2014)
Google Earth
Google Earth es un geonavegador que tiene acceso a imágenes satelitales y aéreas, batimetría oceánica, y otros datos geográficos a través de Internet para representar a la Tierra como un globo tridimensional. Geonavegadores se conocen alternativamente como globos virtuales o buscadores de la Tierra (Educators, 2013).
Open Street View (OSM)
Es un proyecto colaborativo para crear mapas libres y editables. Los mapas utilizando información geográfica capturada con dispositivos GPS móviles, ortografías y otras fuentes libres. Esta cartografía, tanto las imágenes creadas como los datos vectoriales almacenados en su base de datos, se distribuye bajo licencia abierta Open Database License (ODbL) . (OpenStreetMap, 2014)
2.3 Geolocalización en dispositivos móviles
El avance de las nuevas tecnologías y el uso cada vez más generalizado de dispositivos móviles que en la actualidad ya vienen incorporados al mercado con un chip GPS3 integrado o cuentan con servicios GPS asistido, han propiciado un aumento en la utilización de servicios de geolocalización por parte de la población.
Estas tecnologías permiten conocer dónde se encuentra el dispositivo en un momento dado, Basándose una combinación de hardware y software (Avila, 2011).
3 El sistema de posicionamiento global es un sistema que permite determinar en todo el mundo la posición de un objeto (una persona, un vehículo)
9
2.4 Tecnología Móvil 2.4.1 Dispositivos móviles
Un dispositivo móvil se puede definir como un aparato de tamaño pequeño, con algunas capacidades de procesamiento, con conexión permanente o intermitente a una red, que puede llevar a cabo tanto funciones específicas como generales (techopedia, s.f.).
Con el pasar del tiempo las empresas que se encargan de producir estos dispositivos inteligentes fueron evolucionando su funcionamiento, según las necesidades de los usuarios finales, considerando características particulares que cada uno dispone, como: memoria limitada, soporte de un lenguaje y entorno específico.
2.5 Sistema Operativo Móvil
Un sistema operativo móvil o comúnmente denominado SO móvil, de un teléfono inteligente o tableta, significa la interacción real con lo que podemos hacer a partir de las capacidades del hardware que conforman un equipo. Básicamente, es la plataforma que interpreta lo que el usuario quiere que la terminal del dispositivo realice (Amate, 2014).
Existen más de 15 sistemas operativos móviles actuales, solo nombraremos los que sobresalen en el mercado mundial, como ser:
Android iOS Windows Phone
A continuación, se dará relevancia a dos de los sistemas operativos más destacados y de alto impacto en el mercado de telefonía.
Android
Es un sistema operativo multidispositivo, inicialmente diseñado para teléfonos móviles. En la actualidad se puede encontrar también en múltiples dispositivos, como ordenadores,
10
tabletas, GPS2, televisores, discos duros multimedia, mini ordenadores, cámaras de fotos, etcétera. Incluso se ha instalado en microondas y lavadoras. Está basado en Linux, que es un núcleo de sistema operativo libre, gratuito y multiplataforma. (Robledo Fernández, 2014)
Tabla 2.1 Información de SO Android.
Sistema Operativo Android
Modelo de Desarrollo Código abierto
Última Versión Estable Android 6.0
Método de Actualización Google Play
Licencia Apache 2.0 y GNU GPL 2
C (núcleo), C++ (algunas bibliotecas de Escrito en terceros), Java (UI)
Núcleo Linux
Tipo de Núcleo Monolítico
Interfaz gráfica por defecto Material Design
Plataformas Soportadas ARM, x86, MIPS, IBM POWER
Idiomas Multilenguaje iOS
Es un sistema operativo (SO) que pertenece a la empresa Apple Inc. Desarrollado específicamente para cada uno de sus dispositivos. Una de las características principales de la interfaz de este sistema operativo es su simplicidad, sin descuidar su óptimo rendimiento.
En cuanto a la seguridad de este SO, utiliza un estricto control de protección para acceder a la información personal del propietario, mientras que la funcionalidad de hardware y firmware están diseñadas para protegerse contra el malware y los virus, en la tabla 2.1 se detalla características de este SO.
11
Tabla 2.2 Información de SO iOS Sistema Operativo iOS Modelo de Desarrollo Software propietario Última Versión Estable iOS 9.1 Método de Actualización Mediante el dispositivo o Mediante iTunes. Licencia Apple License (APSL y Apple EULA) Escrito en C, C++, Objective-C, Swift Núcleo XNU Tipo de Núcleo Núcleo híbrido (XNU) Interfaz gráfica por defecto Cocoa Touch (Multitáctil, GUI) Plataformas Soportadas ARM (iPad, iPhone y iPod Touch) Idiomas Multilenguaje
2.5.1 Justificación de la selección del SO
Se revisaron y analizaron las diferentes ventajas y desventajas de los diferentes SO móviles, como ser rendimiento, seguridad y evolución, los que más sobresalen son iOS y Android. Cabe recalcar que, a diferencia de Android, iOS está desarrollado únicamente para unos pocos dispositivos diseñados por la propia empresa Apple, constituyendo así un “ecosistema cerrado”.
Los sistemas operativos móviles más frecuentes utilizados por los teléfonos inteligentes son Android (de Google), iOS (de Apple), Windows Phone (de Microsoft) y BlackBerry OS (de BlackBerry). Otros sistemas operativos de menor uso son Bada (de Samsung), Symbian (de Nokia), Firefox OS (de Mozilla), MeeGo (de Moblin y Maemo), webOS, Windows CE, etc. Según datos del tercer trimestre de 2013 (Llamas & Reith, 2014)en cuanto a uso de sistemas operativos móviles en teléfonos inteligentes en todo el mundo, estos fueron los resultados:
12
Sistemas Operativos(%)
Android 12,1 Ios Windows Phone 1,8 3,6 BlackBerry OS 0,3 0,2 Bada 0,2 Symbian OS 0,2 Firefox OS 81,9 Otros
Figura 2.1 Cuadro estadístico de los Sistemas Operativos en teléfonos inteligentes en todo el mundo. Fuente: (Llamas & Reith, 2014)
Después de realizar un revisión y análisis del control de calidad, características, funcionalidades, interfaz de desarrollo y lenguaje de programación a cada sistema operativo, se llegó a una justificación razonable de los datos estadísticos vistos anteriormente, considerando al mismo tiempo que Android es un sistema que lleva tiempo en el mercado y Ios tiene una preferencia en sus seguidores , lo que hace que tenga mejor soporte en software, por tanto los sistema operativos escogido para el desarrollo de la aplicación en el presente proyecto es Multiplataforma.
2.5.1.1 Aplicaciones Nativas
Las aplicaciones nativas tienen archivos ejecutables binarios que se descargan directamente al dispositivo y se almacenan localmente. El proceso de instalación lo puede iniciar el usuario o, en algunos casos, el departamento de TI de la empresa. La manera más común de descargar una aplicación nativa es visitando una tienda de aplicaciones, como App Store de Apple, Marketplace de Android o App World de BlackBerry, pero existen otros métodos que a veces ofrece el proveedor móvil. Una vez que la aplicación ha sido instalada en el dispositivo, el
13
usuario la ejecuta como cualquier otro servicio del dispositivo. Tras la inicialización, la aplicación nativa se conecta directamente con el sistema operativo móvil, sin ningún intermediario ni contenedor.
La aplicación nativa puede acceder libremente a todas las APIs que el proveedor del SO ponga a disposición y, en muchos casos, tiene características y funciones únicas que son típicas de ese SO móvil en particular (IBM, 2012).
2.5.1.2 Interfaz de Programación de Aplicaciones(API)
Una vez que la aplicación nativa está instalada en el dispositivo móvil y es ejecutada por el usuario, interactúa con el sistema operativo móvil a través de llamadas API propietarias de las que dispone el sistema operativo. Estas se pueden dividir en dos grupos: APIs de bajo nivel y APIs de alto nivel.
APIs de bajo nivel
Es a través de las llamadas API de bajo nivel que la aplicación puede interactuar directamente con la pantalla táctil o el teclado, y así mostrar gráficos, conectarse a redes, procesar audio recibido por el micrófono, reproducir sonidos por el altavoz o auriculares, o recibir imágenes y videos de la cámara. Puede acceder al GPS, recibir información sobre orientación y, por supuesto, leer y escribir archivos en el disco en estado sólido o acceder a cualquier otro elemento de hardware disponible en la actualidad o en el futuro.
APIs de alto nivel
Además de proporcionar los servicios de bajo nivel para acceder al hardware que acabamos de mencionar, los sistemas operativos móviles ofrecen servicios de alto nivel que son importantes para la experiencia móvil del usuario. Esos servicios incluyen procesos tales como navegar por Internet, gestionar el calendario, los contactos, álbumes de fotos y, por supuesto, la capacidad de hacer llamadas telefónicas o enviar y recibir mensajes de texto.
14
Aunque la mayoría de los SOs móviles incluyen un conjunto de aplicaciones incorporadas que pueden ejecutar esos servicios, existe un conjunto de APIs de alto nivel expuesto accesible para aplicaciones nativas también, lo que les permite acceder a muchos de los servicios importantes que acabamos de mencionar. Otras APIs permiten que las aplicaciones descargables accedan a diversos servicios en la nube ofrecidos por el distribuidor del SO, tales como notificaciones push o compras en tiendas de aplicaciones. En la Tabla 2.3 observamos las tecnologías que usan los diferentes sistemas operativos de dispositivos móviles.
Tabla 2.3 Interfaces de programación de aplicaciones (API) de los Sistemas Operativos en teléfonos inteligentes Android Apple Ios Windows Phone Blackberry OS Lenguajes Java (algunos Objective-C, C#, VB.NET, etc. Java C, C++) C, C++ Herramientas Android Xcode Visual Studio, BB Java Eclipse Studio Windows Phone Plug-in Formato .apk .app .xap .cod
Tiendas Google Play Apple App Windows Phone Blackberry App Store Marketplace World
A continuación, citamos las ventajas y desventajas del desarrollo de aplicaciones móviles nativas.
Ventajas
• Utilización de los recursos tantos del sistema como del hardware. • Permite ser publicada en tiendas para su distribución. • En su mayoría, no necesitan estar conectadas a Internet para su funcionamiento.
Desventajas
• Solo pueden ser utilizadas por un dispositivo que cuente con el sistema para el cual fue desarrollada. • Requiere de un costo para distribuirla en una tienda, y dependiendo el sistema, para el uso del entorno de desarrollo.
15
• Necesitan aprobación para ser publicadas en la plataforma.
2.5.1.3 Aplicaciones Móviles basadas en la Web
Los dispositivos móviles modernos cuentan con poderosos navegadores que dan soporte a muchas funcionalidades nuevas de HTML5, Cascading Style Sheets 3 (CSS3) y JavaScript de avanzada. Con los últimos avances logrados, HTML5 marca la transición de esta tecnología desde un “lenguaje de definición de páginas” a un poderoso estándar de desarrollo de aplicaciones complejas basadas en navegador.
Una de las principales ventajas de una aplicación Web es su soporte para múltiples plataformas y el bajo costo de desarrollo. La mayoría de los proveedores móviles utilizan el mismo motor de búsqueda en sus navegadores, llamado WebKit, que es un proyecto de fuente abierta conducido principalmente por Google y Apple y que ofrece la más completa implementación de HTML5 disponible en la actualidad. En la tabla 2.4 observamos algunas de las características de las aplicaciones basadas en la Web.
Tabla 2.4 Características de aplicaciones móviles basadas en la Web Características Aplicación. Web solo móviles Sitios Web solo móviles Herramientas y Escritas totalmente en HTML, Escritas totalmente en HTML, CSS Conocimientos CSS y JavaScript y JavaScript Ejecución Acceso directo “Instalado”, Navegando por un sitio mediante lanzado mediante aplicacion. URL (Uniform Resource Locator) nativa Experiencia del Touch-friendly, interactive UI IU mediante navegación entre Usuario páginas que muestran datos estáticos Desempeño IU reside localmente: aplicación Todo el código se ejecuta desde un con capacidad de respuesta y servidor: el acceso offline rendimiento depende de la red
A continuación, citamos las ventajas y desventajas del desarrollo de aplicaciones móviles basadas en la Web.
16
Ventajas
Pueden ser utilizadas desde cualquier dispositivo sin importar el sistema operativo. Puede que requiera un coste para su desarrollo, peor este puede ser mínimo en comparación con las nativas. No requieren de ninguna aprobación para su publicación.
Desventajas
No pueden ser publicadas en plataformas para su distribución No utilizan los recursos del sistema ni del dispositivo de manera óptima.
2.5.1.4 Aplicaciones Hibridas
El enfoque híbrido combina desarrollo nativo con tecnología Web. Usando este enfoque, los desarrolladores escriben gran parte de su aplicación en tecnologías Web para múltiples plataformas, y mantienen el acceso directo a APIs nativas cuando lo necesitan.
La porción nativa de la aplicación emplea APIs de sistemas operativos para crear un motor de búsqueda HTML incorporado que funcione como un puente entre el navegador y las APIs del dispositivo.
Este puente permite que la aplicación híbrida aproveche todas las características que ofrecen los dispositivos modernos. Los desarrolladores de aplicaciones pueden optar por codificar su propio puente o bien aprovechar soluciones ya construidas, como PhoneGap, una biblioteca de fuente abierta que provee una interfaz JavaScript uniforme para funcionalidades de dispositivos seleccionados que son iguales en todos los sistemas operativos.
La porción nativa de la aplicación se puede desarrollar independientemente, pero algunas soluciones del mercado ofrecen este tipo de contenedor nativo como parte de su producto, lo que brinda al desarrollador formas de crear una aplicación avanzada que utilice todas las funciones del dispositivo usando únicamente lenguajes Web.
17
En algunos casos, una solución va a permitir que el desarrollador utilice cualquier conocimiento nativo que pueda tener para adaptar el contenedor nativo a las necesidades únicas de la organización.
La porción Web de la aplicación puede ser una página Web que resida en un servidor o bien un conjunto de archivos HTML, JavaScript, CSS y medios, incorporados en el código de la aplicación y almacenados localmente en el dispositivo. Ambos enfoques presentan ventajas y desventajas.
El código HTML que está alojado en un servidor permite que los desarrolladores introduzcan pequeñas actualizaciones en la aplicación sin tener que seguir el proceso de entrega y aprobación que algunas tiendas de aplicaciones requieren.
A continuación, citamos las ventajas y desventajas del desarrollo de aplicaciones móviles Hibridas.
Ventajas
Uso de los recursos del dispositivo y del sistema operativo El costo de desarrollo puede ser menor que el de una nativa Son multiplataforma Permite distribución a través de las tiendas de su respectiva plataforma.
Desventaja
La documentación puede ser un poco escasa y desordenada.
2.5.2 Comparación de los distintos enfoques de aplicaciones
A modo de resumen se puede observar en la figura 2.2, que a continuación, se comparan los tres enfoques de desarrollo.
18
Aplicación Nativa Aplicación Web Aplicación Hibrida
010101011010101010 100101010101010100 000111111010101010
101010101010101010
Documen 010001010101010101 t</titleCódigo> Web </head> <body></p><p></body> </html> API del Dispositivo API del Dispositivo</p><p>Figura 2.2 Comparación de los distintos enfoques Fuente: (IBM, 2012) </p><p>El enfoque nativo se destaca por su desempeño y acceso de los dispositivos, pero conlleva costos y requiere actualizaciones. El enfoque Web es mucho más simple, menos costoso y más fácil de actualizar, pero actualmente su funcionalidad es limitada y no puede alcanzar un alto nivel de experiencia del usuario como el de las llamadas API nativas. </p><p>El enfoque híbrido ofrece un término medio que, en muchas situaciones, constituye lo mejor de ambos mundos, en especial si el desarrollador desea emplearlo en múltiples sistemas operativos. </p><p>Como se puede observar en la tabla 2.5, ninguno de los enfoques en sí mismo ofrece todos los beneficios todo el tiempo. Para elegir el enfoque más adecuado hay que tener en cuenta las necesidades específicas de la organización, y basarse en muchos parámetros, como presupuesto, plazos de entrega, recursos internos, mercado objetivo, funcionalidad requerida de la aplicación, infraestructura de TI, etc. </p><p>Hay algo que es muy claro: La mayoría de las empresas actuales tienen que encontrar un punto medio, por un lado, entre la experiencia del usuario y la funcionalidad de las aplicaciones y, por el otro, entre los costos de desarrollo y el tiempo de salida al mercado. El desafío consiste en elegir el enfoque de desarrollo correcto que logre un equilibrio entre los requisitos de la organización con sus limitaciones vinculadas al presupuesto y al tiempo de salida al mercado. </p><p>19 </p><p>Tabla 2.5 Comparación de los distintos enfoques de aplicación móviles Aplicación Característica Aplicación Hibrida Aplicación Web Nativa Nativo y Web o solo Lenguaje de desarrollo Solo nativo Solo Web nativo Portabilidad y Bajo Alto Alto optimización de código Características de acceso específicas Alto Mediano Bajo del dispositivo Uso de conocimiento Bajo Alto Alto existente Gráficos avanzados Alto Mediano Mediano Flexibilidad de Bajo (Siempre Mediano (Con Alto actualizaciones Tiendas) frecuencia Tiendas) Experiencia de Alta (A partir de Alta (A partir de la Mediana (Mediante instalación la tienda) tienda) navegador móvil) </p><p>2.6 Servicios en la Nube </p><p>La computación en la nube,1 conocida también como servicios en la nube, informática en la nube, nube de cómputo o nube de conceptos (del inglés cloud computing), es un paradigma que permite ofrecer servicios de computación a través de una red, que usualmente es Internet. Antes de la computación en la nube se tenía el modelo clásico de contar con software comercial que debía ser adquirido generalmente por volumen de licencias, e instalado en los ordenadores de una oficina, por ejemplo. Esto conllevaba a tener que actualizar al mismo tiempo el hardware tiempo y dinero, de implementación del nuevo software adquirido, además del mantenimiento y otros (ITNews, 2013). En cambio, ahora, con el modelo de computación en la nube, una empresa no tiene que preocuparse por requisitos de hardware o por implementar software en sus ordenadores, ya que llega a alquilar estos servicios por costos mínimos. </p><p>Una de las cosas más interesantes de las soluciones de computación en la nube es que tiene el modelo de precios “paga por lo que usas”. Esto quiere decir que un cliente paga solo por su consumo real. </p><p>20 </p><p>A continuación, se mencionará algunas ventajas de servicios en la nube: </p><p>• El costo mensual es mínimo comparado con el gasto que se pudiera tener en caso de que la empresa quisiera comprar el equipo para proporcionar o tener el servicio • Facilidad de uso y administración. No es necesario contar con un administrador de redes ni de seguridad para poder dar el servicio a la empresa. • No se necesitan licencias para poder usar software, solo pagar el servicio mensual. • No se necesita contar con una infraestructura tecnológica. • Las empresas solo necesitan enfocarse en aprender a usar las herramientas tecnológicas. • Las empresas que contratan los servicios siempre contarán con lo último de las actualizaciones de tecnología relacionada con infraestructura y software. • Es posible compartir información y acceder a los servicios desde casi cualquier parte del mundo. • Si surgen problemas con el servicio el proveedor los resolverá </p><p>2.6.1 Base de datos en la nube </p><p>Una base de datos en la nube es una base de datos que se ejecuta en la nube. Hay dos modelos de implementación: los usuarios pueden ejecutar las bases de datos en la nube de forma independiente, utilizando una imagen de máquina virtual, o pueden comprar el acceso a un servicio de base de datos, gestionada por un proveedor de base de datos en la nube (Agrawal, 2008). </p><p>De esta manera uno no tiene que preocuparse por: </p><p>• Tener hardware lo suficientemente robusto para almacenar y procesar datos. • Software para el manejo de la base de datos. • Escalabilidad de la base de datos. • Disponibilidad de la base de datos, frente a distintos problemas. • Mantenimiento de la base de datos. </p><p>21 </p><p>2.6.2 Estructura de los servicios en la nube Firebase </p><p>Firebase es un proveedor de servicios en la nube y back-end como un servicio de la compañía con sede en San Francisco, California. La compañía fabrica una serie de productos para desarrolladores de software que crean aplicaciones móviles o web. La compañía fue adquirida por Google en octubre de 2014. (Wikipedia,2015). </p><p>Es suficiente tener una sola cuenta en Firebase para poder gestionar múltiples aplicaciones móviles o web, esto es útil si tiene una aplicación, ya que se puede implementar diferentes versiones de prueba y producción. Cada aplicación tiene su propio ID de aplicación y clave de cliente que se aplican al desarrollo de la aplicación. En la figura 2.7 se aprecia la arquitectura del servicio móvil a través de Firebase. </p><p>Datos Firebase</p><p>Nube</p><p>Usuarios</p><p>CP Id</p><p>Nombre</p><p>Apellido Interface Web de Datos </p><p>Figura 2.3 Arquitectura de un servicio móvil </p><p>22 </p><p>2.7 Entorno de desarrollo para móviles </p><p>Un entorno de desarrollo integrado (IDE), es un entorno de programación que ha sido un editor de empaquetado como un programa de aplicación, es decir que consiste en código, un compilador, un depurador y un constructor de interfaz gráfica (GUI). Los IDEs pueden ser aplicaciones por sí solos o pueden ser parte de aplicaciones existentes, a continuación de citaran los más destacados y conocidos. </p><p>Intel XDK </p><p>Es una herramienta para desarrollar apps cross-plataform utilizando HTML5. Con XDK, los desarrolladores pueden programar usando tecnologías estándar como HTML5 y desde una misma base de código generar apps para distintas plataformas. Con XDK es posible construir apps para las siguientes plataformas: </p><p>• Aplicaciones móviles: iOS, Android (nativo, Cordova, Crosswalk), Windows 8 Store, Windows Phone 8, <a href="/tags/Tizen/" rel="tag">Tizen</a>, y Nook. • Aplicaciones web: Web, Chrome App, Fracebook App. </p><p>El XDK cuenta con un ambiente de desarrollo que permite emular apps en dispositivos virtuales para darse cuenta de cómo se verá su app en distintos dispositivos (iPhone, Microsoft Surface, Google Nexus, entre otros). </p><p>XDK también ofrece la capacidad de que los desarrolladores puedan almacenar su código en la nube de manera gratuita. La mejor parte del <a href="/tags/Intel/" rel="tag">Intel</a> XDK es que es gratuito y que se puede utilizar tanto en Windows como Mac y Linux (Intel, 2014). </p><p>23 </p><p>2.8 Kit de desarrollo 2.8.1 Ionic framework </p><p>Ionic es un Framework de código abierto SDK para desarrollo de aplicaciones móviles híbridas. Construido sobre angularjs y Apache Cordova, ionic ofrece herramientas y servicios para el desarrollo de aplicaciones móviles híbridos utilizando tecnologías web como CSS, HTML5, y Sass. Las aplicaciones pueden ser construidas con estas tecnologías Web y luego distribuidos a través de tiendas nativas de aplicaciones para instalar en los dispositivos mediante el aprovechamiento de Córdoba. Ionic fue creado por Max Lynch, Ben Sperry, y Adam Bradley de Drifty Co. en 2013, y es utilizado por los desarrolladores de software de todo el mundo (Ionic, 2013) </p><p>Figura2.4 Ionic Framework 2.8.1.1 Apache Cordova </p><p>Apache Cordova es un framework de desarrollo móvil de código abierto. Que permite el uso de las tecnologías web estándar, como HTML5, CSS3 y JavaScript para el desarrollo multiplataforma, evitando el desarrollo del lenguaje nativo de cada plataforma móvil, figura 2.5. Las Aplicaciones se ejecutan dentro de envoltorios específicos para cada plataforma, y se basan en estándares compatibles con fijaciones API para acceder a los sensores, los datos y el estado de la red de cada dispositivo. </p><p>Apache Cordova maneja API que permiten tener acceso a elementos como el acelerómetro, la cámara, los contactos en el dispositivo, la red, el almacenamiento, las notificaciones, etc. Estas API se conectan al sistema operativo usando el código nativo del sistema huésped a través de una Interfaz de funciones foráneas en Javascript. </p><p>24 </p><p>Apache Cordova permite el desarrollo ya sea ejecutando las aplicaciones en nuestro navegador web, sin tener que utilizar un simulador dedicado a esta tarea, y brinda la posibilidad de soportar funciones sobre frameworks como Sencha Touch o JQuery Mobile. </p><p>Figura 2.5 Arquitectura de un Apache Cordova 2.8.1.2 Java Script </p><p>JavaScript (abreviado comúnmente "JS") es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico. </p><p>Se utiliza principalmente en su forma del lado del cliente (client-side), implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas, aunque existe una forma de JavaScript del lado del servidor (Server-side JavaScript o SSJS). Su uso en aplicaciones externas a la web, por ejemplo, en documentos PDF, aplicaciones de escritorio (mayoritariamente widgets) es también significativo. </p><p>25 </p><p>JavaScript se diseñó con una sintaxis similar al C, aunque adopta nombres y convenciones del lenguaje de programación Java. Sin embargo, Java y JavaScript no están relacionados y tienen semánticas y propósitos diferentes. </p><p>Todos los navegadores modernos interpretan el código JavaScript integrado en las páginas web. Para interactuar con una página web se provee al lenguaje JavaScript de una implementación del Document Object Model (DOM). </p><p>Tradicionalmente se venía utilizando en páginas web HTML para realizar operaciones y únicamente en el marco de la aplicación cliente, sin acceso a funciones del servidor. Actualmente es ampliamente utilizado para enviar y recibir información del servidor junto con ayuda de otras tecnologías como AJAX. JavaScript se interpreta en el agente de usuario al mismo tiempo que las sentencias van descargándose junto con el código HTML. </p><p>Desde el lanzamiento en junio de 1997 del estándar ECMAScript, han existido las versiones 2, 3 y 5, que es la más usada actualmente (la 4 se abandonó5). En junio de 2015 se cerró y publicó la versión ECMAScript 6 (ecma, 2015) . </p><p>2.8.1.3 Angular Js </p><p>AngularJS es un framework de JavaScript de código abierto, mantenido por Google, que ayuda con la gestión de lo que se conoce como aplicaciones de una sola página. Su objetivo es aumentar las aplicaciones basadas en navegador con capacidad de Modelo Vista Controlador (MVC), en un esfuerzo para hacer que el desarrollo y las pruebas sean más fáciles. </p><p>La biblioteca lee el HTML que contiene atributos de las etiquetas personalizadas adicionales, entonces obedece a las directivas de los atributos personalizados, y une las piezas de entrada o salida de la página a un modelo representado por las variables estándar de JavaScript. Los valores de las variables de JavaScript se pueden configurar manualmente, o recuperados de los recursos JSON estáticas o dinámicas (Green, 2015). </p><p>26 </p><p>Figura 2.6 Angular Js 2.8.1.3.1 El Patrón MVC </p><p>El patrón MVC (modelo vista controlador) es uno de los patrones de programación más populares para desarrollo de aplicaciones y permite administrar una aplicación, separando los datos, la interfaz e interactividad en diferentes capas independientes (MSDN, 2014). </p><p>El modelo–vista–controlador (MVC) es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado, define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento. </p><p>La figura 2.7 muestra la relación entre el modelo, la vista y el controlador, las líneas sólidas indican una asociación directa, y las punteadas una indirecta (por ejemplo, patrón Observer). </p><p>27 </p><p>Controlador</p><p>Vista Modelo</p><p>Figura 2.7 Modelo Vista Controlador </p><p>De manera genérica, los componentes de MVC se podrían definir como sigue: </p><p>El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto, gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación (lógica de negocio). Envía a la 'vista' aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación de información llegan al 'modelo' a través del 'controlador'. </p><p>El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro en una base de datos). También puede enviar comandos a su 'vista' asociada si se solicita un cambio en la forma en que se presenta el 'modelo' (por ejemplo, desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por tanto, se podría decir que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo'. </p><p>28 </p><p>La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere de dicho 'modelo' la información que debe representar como salida. </p><p>2.8.1.3.2 Data binding </p><p>Posiblemente una de las características más populares de AngularJS es el data binding, que consiste en unir en tiempo real los datos de dos elementos, si el valor de uno de esos elementos cambia, el efecto se reflejará de inmediato en el otro elemento enlazado. </p><p>Esta técnica es sumamente útil para realizar cálculos o para representar gráficamente los cambios que realiza el usuario, tradicionalmente la mayoría de los frameworks pueden implementar esta conducta utilizando eventos y funciones adicionales que ocupan tiempo y depuración, en AngularJS el data binding está integrado y no requiere ni siquiera de una linea de código, solo unas cuantas propiedades y tendrás un enlace en dos vías de datos. </p><p>Este tipo de enlaces se hacen en tiempo real y el usuario notará de inmediato el resultado de cualquier cambio o proceso que realice en la aplicación (Solís, 2015). </p><p>2.8.1.4 HTML5 </p><p>HTML5 (HyperText Markup Language, versión 5) es la quinta revisión importante del lenguaje básico de la World Wide Web, HTML. HTML5 especifica dos variantes de sintaxis para HTML: una «clásica», HTML (text/html), conocida como HTML5, y una variante XHTML conocida como sintaxis XHTML5 que deberá servirse con sintaxis XML (application/xhtml+xml). Esta es la primera vez que HTML y XHTML se han desarrollado en paralelo. La versión definitiva de la quinta revisión del estándar se publicó en octubre de 2014. </p><p>Al no ser reconocido en viejas versiones de navegadores por sus nuevas etiquetas, se recomienda al usuario común actualizar su navegador a la versión más nueva, para poder disfrutar de todo el potencial que provee HTML5. </p><p>29 </p><p>El desarrollo de este lenguaje de marcado es regulado por el Consorcio W3C. (w3c, html5, 2014) </p><p>2.8.1.5 CSS3 </p><p>Hoja de estilo en cascada o CSS (siglas en inglés de cascading style sheets) es un lenguaje usado para definir y crear la presentación de un documento estructurado escrito en HTML o XML2 (y por extensión en XHTML). El World Wide Web Consortium (W3C) es el encargado de formular la especificación de las hojas de estilo que servirán de estándar para los agentes de usuario o navegadores. </p><p>La idea que se encuentra detrás del desarrollo de CSS es separar la estructura de un documento de su presentación. </p><p>La información de estilo puede ser definida en un documento separado o en el mismo documento HTML. En este último caso podrían definirse estilos generales con el elemento «style» o en cada etiqueta particular mediante el atributo «style». (w3c, css3, 2014) </p><p>2.9 Análisis y Diseño </p><p>¿Qué es análisis y diseño? </p><p>El análisis pone énfasis en una investigación del problema y los requisitos, en vez de ponerlo en una solución. "Análisis” es un término amplio, es más adecuado calificarlo, como análisis de requisitos (un estudio de los requisitos) o análisis de objetos (un estudio de los objetos del dominio) (Larman, 2003). </p><p>El diseño pone énfasis en una solución conceptual que satisface los requisitos, en vez de ponerlo en la implementación. Por ejemplo, una descripción del esquema de base de datos y objetos de software. Finalmente, los diseños pueden ser implementados (Larman, 2003)Como con el análisis, es más apropiado calificar el término como diseño de objetos o diseño de base de datos. </p><p>30 </p><p>2.9.1 Análisis y Diseño Orientado a Objetos(A/DOO) </p><p>¿Qué son el análisis y el diseño orientado a objetos? </p><p>Durante el análisis orientado a objetos, se presta especial atención a encontrar y describir los objetos o conceptos en el dominio del problema. Por ejemplo, en el caso de sistema de información de la biblioteca, algunos de los conceptos son libro, biblioteca y socio. </p><p>Durante el diseño orientado a objetos, se presta especial atención a la definición de los objetos software y en como colaboran para satisfacer los requisitos. Por ejemplo, en el sistema de biblioteca, un objeto software libro podría tener un atributo título y un método obtener capitulo (ver Figura 2.3). </p><p>Por último, durante la implementación o programación orientada a objetos, los objetos de diseño se implementan, como la clase java libro. </p><p> libro Concepto del dominio titulo Visualización de los conceptos del dominio</p><p>Representación en un lenguaje de programación orientado a objetos</p><p>Figura 2.8 La orientación a objetos presta especial atención a la representación de los objetos Fuente: (Larman, 2003) 2.9.2 Lenguaje Unificado de Modelado (UML) </p><p>El UML (Lenguaje Unificado de Modelado) es una de las herramientas más emocionantes en el mundo actual del desarrollo de sistemas. Esto se debe a que permite a los creadores de sistemas generar diseños que capturen sus ideas en una forma convencional y fácil de comprender para comunicarlas a otras personas (Schmuller, 2001). </p><p>31 </p><p>2.9.3 Por qué es necesario UML </p><p>En los principios de la computación, los programadores no realizaban análisis muy profundos sobre el problema por resolver. Si acaso, garabateaban algo en una servilleta. Con frecuencia comenzaban a escribir el programa desde el principio, y el código necesario se escribía conforme se requería. Aunque anteriormente esto agregaba un aura de aventura y atrevimiento al proceso, en la actualidad es inapropiado en los negocios de alto riesgo (Schmuller, 2001). </p><p>Hoy en día, es necesario contar con un plan bien analizado. Un cliente tiene que comprender que es lo que hará un equipo de desarrolladores; además tiene que ser capaz de señalar cambios si no se han captado claramente sus necesidades (o si cambia de opinión durante el proceso). A su vez, el desarrollo es un esfuerzo orientado a equipos, por lo que cada uno de sus miembros tiene que saber qué lugar toma su trabajo en la solución fina. </p><p>Conforme aumenta la complejidad del mundo, los sistemas informáticos también deberán crecer en complejidad. En ellos se encuentran diversas piezas de hardware y software que se comunican a grandes distancias mediante una red, misma que está vinculada a bases de datos que, a su vez, contienen enormes cantidades de información. </p><p>La clave está en organizar el proceso de diseño de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan y convengan con él (Schmuller, 2001). </p><p>2.9.4 Aplicaciones de UML y patrones en el A/DOO </p><p>UML es una notación visual estándar. Tan útil como aprender una notación, hay más cosas orientadas a objetos importantes que aprender; concretamente, cómo pensar en objetos, cómo diseñar sistemas orientados a objetos. UML no es A/DOO o un método, es simplemente una notación. No es tan útil aprender a hacer diagramas UML sintácticamente correctos y quizás una herramienta CASE para UML, si no se es capaz de crear un diseño excelente o evaluar o mejorar uno existente (Larman, 2003). </p><p>32 </p><p>2.9.5 Modelo Conceptual </p><p>Un modelo conceptual explica los conceptos más significativos en un dominio del problema, identificando los atributos y las asociaciones, y es la herramienta más importante del análisis orientado a objetos. Un modelo conceptual representa cosas del mundo real, no componentes del software. En UML se representa mediante un grupo de es diagramas de estructura estática donde define ninguna operación. En estos diagramas se muestran conceptos (objetos), asociaciones entre conceptos (relaciones) y atributos de conceptos (Larman, 2003). </p><p>2.9.6 Diagrama de Casos de Uso </p><p>Un caso de uso es la descripción de las acciones de un sistema desde el punto de Vista del usuario. Para los desarrolladores del sistema ésta es una herramienta valiosa, ya que es una técnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Esto es importante si la finalidad de crear un sistema que puede ser utilizado por la gente en general y no solo por expertos en computación (Schmuller, 2001) </p><p>Los casos de uso no son propiamente un elemento del análisis y diseño orientado a objetos (pueden ser utilizados en análisis no orientados a objetos), pero constituyen un paso preliminar muy útil porque describen las especificaciones de un sistema. Para especificar los casos de uso en el lenguaje UML, se utiliza una elipse que encierra el nombre del caso (Larman, 2003). Para la descripción del caso de uso se toma en cuenta los siguientes puntos: </p><p>• Nombre de caso de uso • Participantes • Descripción </p><p>2.9.7 Diagrama de Clases </p><p>Una clase es una categoría o grupo de cosas que tienen atributos y acciones similares. Los diagramas de clases colaboran en lo referente al análisis y facilitan las representaciones a partir de las cuales los desarrolladores podrán trabajar. Este diagrama está formado por varios </p><p>33 </p><p> rectángulos conectados por líneas que muestran la manera en que las clases se desarrollan entre sí (Schmuller, 2001) </p><p>2.9.8 Programación Extrema (XP) </p><p>La Programación Extrema PX, mejor conocida por su nombre en inglés Extreme Programming (PX), es una de las llamadas Metodologías Ágiles de desarrollo de software más exitosas de los tiempos recientes, nace como nueva disciplina de desarrollo de software hace aproximadamente unos seis años, y ha causado un gran revuelo entre el colectivo de programadores del mundo. Kent Beck, su autor, es un programador que ha trabajado en múltiples empresas y que actualmente lo hace como Programador en la conocida empresa automovilística DaimlerChrysler. Con sus teorías ha conseguido el respaldo de gran parte de la industria del software (Wells, 2009) </p><p>2.9.9 Las Cuatro variables </p><p>XP define cuatro variables para proyectos de software: coste, tiempo, calidad y ámbito. Además de estas cuatro variables, Beck propone que sólo tres puedan ser establecidas por las fuerzas externas, mientras que el valor de la cuarta variable debe ser establecido por los programadores en función de las otras tres, considerando que es una variable muy importante que nos va a decir dónde vamos a llegar con nuestro software, que problemas vamos a resolver y cuales vamos a dejar para siguientes versiones. (Wells, 2009) </p><p>2.9.10 Los Cuatro Valores </p><p>Una de las cosas que los programadores tienen que tener muy claro es que en el ciclo de vida del desarrollo de un proyecto software los cambios van a aparecer, cambiarán los requisitos, las reglas de negocio, el personal, la tecnología, todo va a cambiar. Por tanto, el problema no es el cambio en sí, ya que este va a suceder sino la incapacidad de enfrentar estos cambios. Como en otra cualquier actividad humana se necesitan valores para desarrollar un trabajo y conseguir los planteamientos iniciales. Se define un conjunto de cinco valores que establecen el fundamento para todo trabajo realizado como parte de XP, y </p><p>34 </p><p> cada uno de estos valores se usa como motor para actividades, acciones y tareas específicas de XP (Pressman, 2005). </p><p>2.9.11 Comunicación </p><p>A fin de lograr la comunicación eficaz entre los ingenieros de software y otros participantes, XP pone el énfasis en la colaboración estrecha pero informal (verbal) entre los clientes y los desarrolladores, en el establecimiento de metáforas para comunicar conceptos importantes, en la retroalimentación continua y evitar la documentación voluminosa como medio de comunicación (Pressman, 2005). </p><p>2.9.12 Sencillez </p><p>Para alcanzar la simplicidad, XP restringe a los desarrolladores para que desarrollen solo para las necesidades inmediatas, en lugar de considerar las del futuro. El objetivo es crear un diseño sencillo que se implemente con facilidad en forma de código. Si hay que mejorar el diseño, se rediseñará en un momento posterior (Pressman, 2005). </p><p>2.9.13 Retroalimentación </p><p>Se obtiene de tres fuentes: el software implementado, el cliente y desarrollador. Al diseñar e implementar una estrategia de pruebas eficaz, el software da retroalimentación al equipo ágil. XP usa la prueba unitaria como su táctica principal de pruebas. </p><p>A medida que se desarrolla cada clase, el equipo implementa una prueba unitaria para ejecutar cada operación de acuerdo con su funcionalidad especificada. Cuando entrega un incremento a un cliente, las historias de usuario y casos de uso que se implementan con el incremento se utilizan como base para las pruebas de aceptación. El grado en el que el software implementa la salida, función y comportamiento del caso de uso es una forma de retroalimentación. Por ultimo conforme se obtienen nuevos requerimientos como parte de la </p><p>35 </p><p> planeación iterativa, el equipo da al cliente una retroalimentación rápida con miras al costo y al efecto en la programación de actividades (Pressman, 2005). </p><p>2.9.14 Valentía </p><p>Afirmar que la adhesión estricta a cierta práctica de XP requiere valentía. Por ejemplo, es frecuente que haya mucha presión para diseñar requerimientos futuros. La mayor parte de equipos de software sucumben a ella y se justifican porque "diseñar para el mañana ahorrará tiempo y esfuerzo en el largo plazo. Un equipo XP debe tener la disciplina (valentía) para diseñar para hoy y reconocer que los requerimientos futuros tal vez cambien mucho, por lo que demandaran repeticiones sustanciales del diseño y del código implementado (Pressman, 2005). </p><p>2.9.11 El Proceso XP </p><p>La programación extrema usa un enfoque orientado a objetos como paradigma preferido de desarrollo, y engloba un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades estructurales: planeación, diseño, codificación y pruebas. La figura 2. ilustra el proceso XP y resalta alguna de las ideas y tareas clave que cada actividad estructural (Pressman, 2005). A continuación, se mencionarán las fases de XP. </p><p>36 </p><p>Figura 2.9 Proceso XP Fuente: (Pressman, 2005) 2.9.11.1 Fase de Exploración </p><p>En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología. </p><p>2.9.11.2 Fase de Planificación </p><p>En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos días. </p><p>37 </p><p>Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la "velocidad" de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración. </p><p>La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se pueden completar. Al planificar según alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación. </p><p>2.9.11.3 Fase de diseño </p><p>El diseño XP sigue rigurosamente el principio MS (mantenlo sencillo). Un diseño sencillo siempre se prefiere sobre una representación más compleja. Además, el diseño guía la implementación de una historia conforme se escribe: nada más y nada menos. Se desalienta el diseño de funcionalidad adicional porque el desarrollador supone que se requerirá después. XP estimula el uso de las tarjetas CRC como un mecanismo eficaz para pensar en el software en un contexto orientado a objetos. Las tarjetas CRC (clase-responsabilidad-colaborador) identifican y organizan las clases orientadas a objetos que son relevantes para el incremento actual de software. El equipo XP dirige el ejercicio de diseño con el uso de un proceso similar al que se describe en el capítulo 8. Las tarjetas CRC son el único producto del trabajo de diseño que se genera como parte del proceso XP. </p><p>Si en el diseño de una historia se encuentra un problema de diseño difícil, XP recomienda la creación inmediata de un prototipo operativo de esa porción del diseño. Entonces, se implementa y evalúa el prototipo del diseño, llamado solución en punta. El objetivo es </p><p>38 </p><p> disminuir el riesgo cuando comience la implementación verdadera y validar las estimaciones originales para la historia que contiene el problema de diseño (Pressman, 2005). </p><p>2.9.11.4 Fase de Iteración </p><p>Después de que las historias han sido desarrolladas y de que se ha hecho el trabajo de diseño preliminar, el equipo no inicia la codificación, sino que desarrolla una serie de pruebas unitarias a cada una de las historias que van a incluir en la entrega en curso (incremento en software). Una vez creada la prueba unitaria, el desarrollador esta mejor capacitado para centrarse en lo que debe implementarse para pasar la prueba. No se agrega nada extraño (MS). Una vez que el código está terminado, se le aplica de inmediato una prueba unitaria, con lo que se obtiene retroalimentación instantánea para los desarrolladores. Un concepto clave para la actividad de codificación es la programación en parejas. XP recomienda que dos personas trabajen juntas en una estación de trabajo evitando problemas de calidad en lo posterior (Pressman, 2005) </p><p>2.9.11.5 Fase de pruebas </p><p>Las pruebas que se crean deben implementarse con el uso de una estructura que permita automatizarlas (de manera que puedan ejecutarse en repetidas veces y con facilidad). Esto estimula una estrategia de pruebas de regresión siempre que se modifique el código (lo que ocurre con frecuencia, dada la filosofía del rediseño en XP). A medida que se organizan las pruebas unitarias individuales en un grupo de pruebas universal, las pruebas de integración y validación del sistema pueden efectuarse a diario. Esto da al equipo XP una indicación continua del avance y también lanza señales de alerta si las cosas marchan mal. dice. </p><p>“Corregir ciertos problemas cada cierto número de horas toma menos tiempo de resolver problemas enormes justo antes del plazo final” (Pressman, 2005) </p><p>Las pruebas de aceptación XP, también llamadas pruebas del cliente, son especificadas por el cliente y se centran en las características y funcionalidad general del sistema que son </p><p>39 </p><p> visibles y revisables por parte del cliente. Las pruebas de aceptación de derriban de historias de los usuarios que se han implementado como parte de la liberación del software. </p><p>2.10 Controles de seguridad implementados según recomendación de la OWASP </p><p>Una de las principales prioridades del Proyecto OWASP Mobile Security es ayudar a estandarizar y difundir metodologías de pruebas de aplicaciones móviles. Aunque existen técnicas específicas para las plataformas individuales, un modelo general móvil puede ser utilizado para ayudar a los equipos de prueba en la creación de una metodología de prueba de seguridad móvil para cualquier plataforma (OWASP, 2008). </p><p>El proyecto OWASP Mobile Security va dirigido a los desarrolladores de aplicaciones y los probadores de seguridad. Los desarrolladores y probadores de seguridad pueden usar este proyecto como una guía de referencia para garantizar que se están evaluando adecuadamente la superficie de ataque de aplicaciones móviles. La evaluación móvil ideal que se realiza combina el análisis dinámico, análisis estático, y el análisis forense para asegurar que la mayoría de la superficie de ataque a una aplicación móvil este protegido. A continuación, se mencionan 10 de las medidas de seguridad según OWASP: a) Identificación y protección de los datos confidenciales en el dispositivo móvil </p><p>Riesgos: almacenamiento de datos sensibles en condiciones de riesgo, los ataques a los teléfonos fuera de servicio de divulgación no intencional. </p><p>Los dispositivos tienen un mayor riesgo de pérdida o robo. Una protección adecuada debe ser construida para reducir al mínimo la pérdida de datos confidenciales en el dispositivo. </p><p>Almacenar datos confidenciales en el servidor en lugar del dispositivo de cliente de extremo. Esto se basa en la suposición de que la conectividad de red segura es suficientemente disponible y que los mecanismos de protección disponibles para el almacenamiento de </p><p>40 </p><p> servidor son superiores. La relativa seguridad de cliente frente a la seguridad del lado del servidor también debe ser evaluado sobre una base de caso por caso (ENISA, 2011). b) Manejo de las credenciales de contraseña seguras en el dispositivo </p><p>Riesgos: spyware, la vigilancia, el malware financiero. Las credenciales de un usuario, en caso de robo, no solo permiten el acceso no autorizado al servicio de back-end móvil, sino que también ponen en peligro potencialmente muchos otros servicios y cuentas por el usuario. </p><p> No guardar las contraseñas o secretos en el binario de la aplicación. c) Garantizar que los datos sensibles están protegidos en transito </p><p>Riesgos: La mayoría de los teléfonos inteligentes son capaces de utilizar varios mecanismos de la red, incluyendo Wi-Fi, red de proveedores (4G,3G, GSM CDMA y otras), Bluetooth, etc. Los datos sensibles que pasan a través de canales no seguros podrían ser interceptados. </p><p> Para los datos sencibles, para reducir el riesgo del hombre en medio de los ataques (como proxy de SSL, tira SSL), una conexión segura solo debe establecer después de la verificación de la identidad del punto final remoto (servidor). Esto se puede lograr asegurando que SSL solo se establece con puntos finales que tienen los certificados de confianza de la cadena de clave SMS, MMS o notificaciones no deben utilizarse para enviar datos sensibles hacia o desde puntos finales móviles. d) Implementación de la autenticación del usuario, autorización y gestión de sesiones correctamente </p><p>Riesgos: Las personas no autorizadas pueden tener acceso a datos o sistemas sensibles por eludir los sistemas de autenticación (logins). </p><p>41 </p><p> Exigir la autenticación del usuario apropiado para la aplicación puede ser útil para proporcionar información sobre la fuerza de la contraseña cuando se introduce por primera vez. La fuerza del mecanismo de autenticación utilizado depende de la sensibilidad de los datos que están siendo procesados por la aplicación y su acceso de los datos que están siendo procesados por la aplicación y su acceso a los recursos valiosos. (ENISA, 2011). Es importante asegurarse de que la gestión de la sesión se maneja correctamente después de la autenticación inicial, utilizando protocolos seguros apropiados. e) Mantener la API(s) de backend(servicios) y la plataforma(servidor) seguro </p><p>Riesgos: los ataques contra los sistemas de back-end y la perdida de datos a través de almacenamiento en la nube. La mayoría de las aplicaciones móviles interactúan con las API de back-end que utilizan servicios REST / Web o protocolos propietarios (ENISA, 2011). </p><p> Llevar a cabo una comprobación especifica del código para los datos sensibles involuntariamente transferidos, los datos transferidos entre el dispositivo móvil y el servidor web de regreso termina y otras interfaces externas. Todos los servicios de back-end (Servicios Web / Rest) para aplicaciones móviles deben hacerse la prueba de vulnerabilidades periódicas. f) Integración segura con servicios y aplicaciones de terceros </p><p>Riesgos: fuga de datos. Los usuarios pueden instalar las aplicaciones que pueden ser maliciosos y pueden transmitir los datos personales (u otros datos almacenados sensibles) para fines maliciosos. </p><p> Ver la seguridad / autenticidad de cualquier tercer código / bibliotecas utilizando en una aplicación móvil. Seguimiento de todos los terceros marcos del partido /API utilizadas en la aplicación móvil para los parches de seguridad. </p><p>42 </p><p> Prestar especial atención a la validación de todos los datos recibidos de y enviados a aplicaciones de terceros no son de confianza. g) Consentimiento para la recopilación y el uso de datos del usuario </p><p>Riesgos: Divulgación no intencional de información personal o privada, procesamiento de datos ilegal. En la Unión europea, es obligatorio obtener el consentimiento del usuario para la recogida de información de identificación personal. </p><p> Crear una política de privacidad cubre el uso de los datos personales y hacer que esté disponible para el usuario, especialmente al tomar decisiones de consentimiento. El consentimiento puede ser recogida en tres formas principales: o Al momento de la instalación o En tiempo de ejecución cuando los datos se envían o A través del mecanismo de “opt- out”, donde se implementa una configuración predeterminada y el usuario tiene que apagarlo. Comprobar si la aplicación está recogiendo información de identificación personal, el cual no debe ser siempre evidente. Mantener un registro de consentimiento para la transferencia de información de identificación personal. Este registro deberá estar disponible para el usuario. h) Implementación de controles para autorizar acceso a recursos de pago </p><p>Riesgos: aplicación de teléfonos inteligentes dan acceso programático (automático) a las llamadas telefónicas tasa de suscripción, SMS, datos de itinerantica, los pagos NFC, etc. Aplicaciones con un acceso privilegiado a dichos API deben tener especial cuidado para evitar el abuso, teniendo en cuenta el impacto financiero de las vulnerabilidades que dan a los atacantes acceso a los recursos financieros de los usuarios. </p><p> Garantizar que la devolución de llamada de API billetera no pasan cuenta / precio / facturación información sin cifrar. </p><p>43 </p><p> Avisar al usuario y obtener el consentimiento de las repercusiones en los costos para el comportamiento de aplicaciones. i) Garantizar una segura distribución y actualización de la aplicación móvil </p><p>Riesgos: el uso de las prácticas de distribución de seguros es importante en la mitigación de todos los riesgos que se describen en los OWASP Mobile. Las solicitudes deben ser, diseñados y aprovisionados para permitir actualizaciones de parches de seguridad, teniendo en cuenta los requisitos para la aprobación por las tiendas de aplicaciones autorizadas de los dispositivos y el retardo adicional que esto puede implicar. </p><p> La mayoría de las tiendas de aplicaciones monitorean aplicaciones para codido inseguro y son capaces de eliminar de forma remota aplicaciones a corto plazo en caso de un incidente. Distribuido de aplicaciones a través de tiendes oficiales APP, por lo tanto, proporciona una red de seguridad en caso de graves vulnerabilidades de la aplicación. Canales de retroalimentación para que los usuarios reporten problemas de seguridad con aplicaciones. j) Comprobar los errores en tiempo de ejecución </p><p>Riesgos: interpretación de tiempo de ejecución de código pueden dar una oportunidad a las partes que no se confía para proporcionar información no verificada que se interpreta como código. Por ejemplo, los niveles de extra en un juego, guiones, interpretados cabeceras SMS. Esto le da una oportunidad para que el malware pueda eludir los controles amurallados proporcionados por tiendas de aplicaciones. Puede conducir a ataques de inyección que conducen a la fuga de datos, vigilancia, spyware, y diallerware. </p><p> Minimizar interpretación en tiempo de ejecución y las capacidades que ofrece a los interpretes en tiempo de ejecución: interpretes funcionan a niveles de privilegios mínimos. </p><p>44 </p><p> Realizar pruebas caso de abuso, además de utilizar las pruebas de caso. Validar todas las entradas. Utilizar idiomas seguros. Realice siempre pruebas como estándar, así como un usuario privilegiado. </p><p>45 </p><p>CAPÍTULO III: MARCO APLICATIVO </p><p>3.1 Análisis, Diseño y Desarrollo de la Aplicación </p><p>Después de introducir definiciones referentes al análisis orientado a objetos y el proceso de desarrollo que realiza la metodología extrema (XP), ahora se procederá al desarrollo mediante el uso de la metodología eXtreme Programming (XP), y a realizar un análisis y diseño orientado a objetos (ADOO), con ayuda de herramientas como el lenguaje unificado de desarrollo (UML). </p><p>3.1.1 Análisis y Diseño Para el análisis y diseño de la aplicación se iniciará con la identificación de requerimientos, los diagramas de casos de uso, los diagramas de secuencia con sus respectivos contratos para luego concluir con los diagramas de estado y clase, como se muestra a continuación: 3.1.1.1 Modelo Conceptual </p><p>Para el análisis y diseño de la aplicación se iniciará con la identificación de requerimientos, los diagramas de casos de uso, los diagramas de secuencia con sus respectivos contratos para luego concluir con los diagramas de estado y clase, como se muestra a continuación: </p><p>46 </p><p>Usuario * Obtiene Información de * nombre: Administrador Restaurante 1 Registra-datos del * nombre: </p><p> nombre: 1 1</p><p>Pertenece a * * Contiene</p><p>Categoria Platos</p><p> nombre: nombre: </p><p>Figura 3.1 Modelo Conceptual del administrador, usuario y restaurante 3.1.2 Identificación de Requerimientos </p><p>Para el análisis, el primer paso a considerar será el de definir los requerimientos del sistema. Estos requerimientos serán agrupados en dos grupos: los funcionales y los no funcionales. Estos requerimientos se obtuvieron a través del previo estudio del marco conceptual y el análisis de las funcionalidades. </p><p>3.1.2.1 Requerimientos Funcionales </p><p>Los requerimientos funcionales permitirán definir el comportamiento del sistema: input, output y el flujo de información. Con esta lista de requerimientos se podrá obtener las necesidades del presente software. En la siguiente lista se presentan los requerimientos agrupados en cinco grupos: "Seguridad", "Administración del Sistema", "Reportes", "Flujo Restaurantes" y "Flujo Consumidores". Esta misma organización permitirá más adelante organizar los casos de uso en paquetes. A continuación, la lista: </p><p>47 </p><p>Tabla 3.1 Descripción de Requerimientos Funcionales Código Descripción del requerimiento FUN-01 El sistema debe permitir que existan tres tipos de usuarios: restaurantes, consumidores y administradores. FUN-02 El sistema debe permitir que los Administradores puedan publicar información sobre restaurantes. FUN-03 El sistema debe mostrar la ubicación de los restaurantes georreferenciados. FUN-04 El sistema debe permitir a los usuarios consumidores que critiquen a los restaurantes Flujo Restaurantes FUN-05 El sistema debe permitir registrar nuevos restaurantes mediante una interfaz. FUN-06 El sistema debe permitir a los restaurantes administrar su información a publicar FUN-07 El sistema debe permitir que el restaurante registre su ubicación en un mapa. FUN-08 El sistema debe permitir que las páginas de los restaurantes tengan una sección de donde se publiquen las calificaciones y críticas de otros consumidores. FUN-09 El sistema debe permitir a cada restaurante poseer su propio catálogo de platos y poder administrarlo. Flujo Consumidores FUN-10 El sistema debe permitir el registro de usuarios consumidores mediante una interfaz. FUN-11 El sistema debe permitir a los usuarios consumidores criticar los restaurantes en base a la calidad del servicio, la comida, el ambiente y precio FUN-12 El sistema debe permitir realizar búsquedas con filtros que contengan “nombre del restaurante”, “servicios que brinda”, “tipo de restaurante”, “zona en el que se ubica”, y “tipo de comida. FUN-13 El sistema debe mostrar un mapa en el que se encuentre el restaurante consultado”. FUN-14 El sistema debe permitir a los usuarios consultar restaurantes, su detalle y su ubicación. Seguridad FUN-15 El sistema debe permitir a los distintos usuarios del sistema poder ingresar a este por medio de un inicio de sesión. FUN-16 El sistema debe permitir bloquear el acceso a un usuario en caso este haya ingresado datos de autenticación erróneos una cantidad configurable de veces. FUN-17 El sistema debe permitir a cualquier usuario poder cambiar su contraseña. Total </p><p>48 </p><p>3.1.2.2 Requerimientos no Funcionales Los requerimientos no funcionales no proporcionarán mayor información sobre el comportamiento del sistema (a diferencia de los requerimientos funcionales). Estos serán los requerimientos técnicos del sistema para que pueda cumplir sus funciones. En el siguiente listado se muestran los requerimientos propuestos para la aplicación a implementar, estos requerimientos al ser técnicos podrían estar sujetos a cambios dependiendo de dónde se vaya a implantar la solución. A continuación ver Tabla 3.2: </p><p>Tabla 3.2 Descripción de Requerimientos No Funcionales Código Descripción del requerimiento NFU-01 El sistema debe desarrollarse con herramientas de libre disponibilidad o que posean licencias gratuitas o académicas. NFU-02 El Sistema Operativo en el que se utilice la aplicación deberá tener soporte con mecanismos de geolocalización, tales como Android, Ios, Windows Phone, etc. NFU-03 La aplicación debe ser desarrollada con estándares de programación y una arquitectura que permita que este sea escalable y mantenible en el tiempo. NFU-04 El sistema debe permitir a los administradores dar mantenimiento a los usuarios consumidores para poder darles de baja o reactivarlos. </p><p>3.1.3 Catálogo de actores </p><p>Se detalla a continuación los diferentes actores que interactúan en los procesos de la aplicación, especificando también las acciones realizadas por estos, descritos en la tabla 3.3 </p><p>49 </p><p>Restaurante</p><p>Usuario Consumidor</p><p>Administrador</p><p>Figura 3.2 Diagrama de Actores (Elaboración Propia) </p><p>A continuación, se da a conocer los roles de actores del sistema. Tabla 3.3 </p><p>Tabla 3.3 Roles de actores del Sistema. </p><p>Rol Descripción </p><p>Este actor se encarga de realizar la administración del sistema. Por un lado, administra los maestros de servicios, tipos de local, tipos de cocina, medios de pago con los que los usuarios restaurante podrán registrar sus locales. Por otro lado, se encarga de administrar el flujo de las críticas y quejas que registran los comensales y restaurantes. Finalmente, realiza la configuración adecuada del mecanismo automático que analiza el contenido Administrador textual de las críticas. </p><p>50 </p><p>Este tipo de usuario cumple con las características de representar a un Restaurante para poder incluirlo en la guía gastronómica. Este se encargará de registrar toda la información del restaurante que sea necesaria para poder publicarlo en el sistema, administrará su catálogo de platos, podrá consultar y reportar críticas que otros usuarios hayan realizado hacia él y podrá consultar sus quejas (críticas reportadas) para saber si han sido atendidas por los administradores. Restaurante </p><p>Este actor es cualquier persona natural que desee consultar información acerca de los restaurantes registrados en el sistema. Este cuenta con las funcionalidades de calificar a un restaurante y poseer un perfil, en el cual puede consultar todas las críticas que ha realizado, ya sean aprobadas, rechazadas o pendientes de verificación. </p><p>Consumidor </p><p>3.1.4 Paquetes </p><p>En esta sección, se muestra la paquetería que se aplicará al análisis del sistema con el fin de organizar el sistema para su mejor entendimiento. Estos paquetes englobarán casos de uso que cumplen con tareas estrechamente relacionadas. </p><p> Administración del Sistema: Englobará los casos de uso que se dediquen a la administración general del sistema, administración de los usuarios (restaurantes y consumidores), administración de criterios de búsqueda y gestión de las críticas. </p><p>51 </p><p>Administración del Flujo Restaurantes Sistema</p><p>Seguridad Flujo Consumidores</p><p>Figura 3.3 “Diagrama de Paquete” </p><p> Seguridad: Contendrá los casos de uso que se enfoquen en la seguridad del sistema como son los inicios de sesión, los cambios de contraseña y el desbloqueo de cuentas. Flujo de Restaurantes: Contendrá los casos de uso que se centren en la administración de los restaurantes por parte de los usuarios tipo restaurantes Flujo de Consumidores: Englobará los casos de uso que se enfoquen en las acciones que pueden realizar los consumidores y los usuarios públicos. </p><p>3.1.4.1 Casos de Uso </p><p>Los casos de uso mostrarán las acciones que realizarán los actores del sistema. Estos estarán agrupados en los paquetes que se indicó en el punto anterior </p><p>52 </p><p>3.1.4.1.1 Paquete de Flujo Administración del Sistema </p><p>Administración del Sistema</p><p>Administrar Servicios Administrar Tipos de Locales</p><p>Administrar Tipos de Cocina</p><p>Administrar Críticas de Restaurantes</p><p>Administrador georreferenciar restaurante</p><p>Administrar Usuarios Consumidores</p><p>Administrar Usuarios Restaurantes</p><p>Configurar Gestion de las Criticas Automatizadas</p><p>Figura 3.4 “Paquete Administración del Sistema” 3.1.4.1.2 Paquete de Flujo Restaurantes </p><p>Flujo Restaurantes</p><p>Enviar Solicitud de Nuevo Restaurante</p><p>Administrar Informacion del Restaurante</p><p>Administrar Catalogos de Platos</p><p>Restaurante Consultar Criticas Reportar Criticas</p><p>Figura 3.5 “Paquete Restaurantes” </p><p>53 </p><p>3.1.4.1.3 Paquete de Flujo Consumidores </p><p>Flujo Consumidores</p><p>Registrar Consumidor</p><p>Consultar Restaurantes</p><p>Consultar Detalle de Restaurantes</p><p>Consultar la ubicacion de los restaurantes</p><p>Consultar Perfil Consumidor</p><p>Criticar Restaurante</p><p>Figura 3.6 “Paquete Consumidores” 3.1.4.1.4 Paquete de Seguridad </p><p>Flujo Seguridad</p><p>Identificar Rol</p><p><<include>></p><p>Iniciar Sesión Consumidor Administrador</p><p>Cambiar Contraseña</p><p>Configurar Límite de Intentos Fallidos Restaurante</p><p>Desbloquear Acceso</p><p>Figura 3.7 “Paquete Seguridad” </p><p>54 </p><p>3.1.4.2 Especificación de Casos de Uso </p><p>En este punto, se realizará la especificación de los casos de uso principales para poder entender el funcionamiento del sistema, estos también se presentarán organizados por paquetes como se hizo en las figuras 3.3, 3.4, 3.5 y 3.6. </p><p>Del paquete de “Flujo Consumidores”, los casos de uso más relevantes son los siguientes: </p><p>Tabla 3.4 Especificación del caso de uso Consultar Restaurantes Consultar Restaurantes Id CU-COM-002 Descripción Este caso de uso muestra cómo se realizan las búsquedas de restaurantes </p><p>Referencia a FUN-14 </p><p> lista de </p><p>Datos requerimientos Paquete Flujo Consumidores Actores Consumidor </p><p>Pre-condición El actor debe encontrarse en la página de búsqueda de la aplicación. </p><p>Flujo Principal: “Búsqueda Normal” Acción del Actor Respuesta del Sistema </p><p>1. El actor debe ingresar el nombre de algún 2. El sistema procesa la consulta y muestra un listado restaurante en el Buscador. de restaurantes de acuerdo al filtro con los siguientes datos: Nombre, Cocina, Dirección, Calidad de Comida, Calidad de Servicio, Calidad de Ambiente, Precio Promedio, y Cantidad de Votos </p><p>Post-condición Flujo principal Se mostró un listado de restaurantes </p><p>55 </p><p>Tabla 3.5 Especificación del caso de uso Opinión al Restaurante Criticar Restaurante Id CU-COM-005 Descripción Este caso de uso muestra el flujo de cómo el cliente califica a un restaurante. </p><p>Referencia a FUN-04, FUN-13 </p><p>Datos lista de requerimientos Paquete Flujo Consumidores Actores Consumidor </p><p>Pre-condición El actor debe haber iniciado sesión. </p><p>Flujo Principal: “Calificar Restaurante” Acción del Actor Respuesta del Sistema </p><p>1. El actor consulta el detalle de un restaurante 2. El sistema mostrará el detalle de todo el siguiendo el flujo del caso de uso CU-COM- restaurante. 003. </p><p>3. El actor selecciona la opción Calificar 4. El sistema mostrará el nombre del restaurante. Restaurante. Asimismo, mostrará cuatro criterios de evaluación: </p><p>Comida, Servicio, Ambiente y Precio. Los tres primeros criterios podrán ser calificados bajo el siguiente rango: Mala, Regular, Buena, Muy Buena, Excelente que corresponden a los valores de 1 a 5. En cuanto al criterio de Precio se ingresará un precio promedio que incluya entrada, plato principal y bebidas. Finalmente, se mostrará un campo que se llame Comentarios, en el cual se ingresará un texto, y la opción Calificar </p><p>56 </p><p>5. El actor llenará los campos mencionados en 6. El sistema mostrará el siguiente mensaje: Gracias el punto anterior y seleccionará la opción por calificar al restaurante X, se procesará su Calificar. comentario lo más rápido posible para que sea publicado en la página web. </p><p>Post-condición Flujo principal Se mostró una calificación en el sistema. </p><p>Flujo alterno1:” Criterios Vacíos” </p><p>1. En el punto 5 del flujo principal, el actor no 2. El sistema valida los criterios y, para los que estén llena todos los criterios de calificación y vacíos, mostrará el mensaje Por favor indique un selecciona la opción Calificar. valor para este criterio. </p><p>3. El actor volverá al punto 5 del flujo principal 4. El sistema mostrará el siguiente mensaje: Gracias hasta que llene correctamente todos los criterios por calificar al restaurante X, se procesará su y seleccione la opción Calificar. comentario lo más rápido posible para que sea publicado en la página web. </p><p>Post-condición Flujo alterno 1: Se registró una calificación en el sistema. </p><p>Flujo alterno 2: “Comentarios Incompletos” </p><p>57 </p><p>1. En el punto 5 del flujo principal, el actor llena 2. El sistema valida los criterios y los comentarios, y los criterios, coloca un comentario con menos muestra un mensaje La reseña debe tener más de 100 de 100 caracteres y selecciona la opción Votar caracteres. </p><p>3. El actor volverá al punto 5 del flujo principal 4. El sistema mostrará el siguiente mensaje: Gracias hasta que llene correctamente los criterios y el por calificar al restaurante X, se procesará su comentario y seleccione la opción Calificar. comentario lo más rápido posible para que sea publicado en la página web. </p><p>Post-condición Flujo alterno2: Se registró una calificación en el sistema </p><p>Del paquete de “Administración del Sistema”, los casos de uso más relevantes son los siguientes: </p><p>Por último, del paquete de “Flujo Restaurantes”, los casos de uso más relevantes son los siguientes: </p><p>Tabla 3.6 Especificación del caso de uso Enviar Solicitud de Nuevo Restaurante. Enviar Solicitud de Nuevo Restaurante Id CU-REST-001 Descripción Consiste en que los restaurantes puedan enviar solicitudes con información sobre ellos para que puedan formar parte del sistema y, así poder publicar </p><p> su información y administrarla </p><p>Datos Referencia a FUN-06 lista de requerimientos Paquete Flujo Restaurantes Actores Restaurantes </p><p>58 </p><p>Pre-condición El actor aún no se encuentra registrado en el sistema y se encuentra en la página principal del sistema </p><p>Flujo Principal: “Enviar Solicitud” Acción del Actor Respuesta del Sistema </p><p>1. El actor debe seleccionar la opción Agregar 2. El sistema mostrará distintas secciones en las que Restaurante. se deberá colocar la información sobre el restaurante. Primero se encuentran los Datos Generales con los </p><p> siguientes campos: nombre del restaurante, ciudad, zona, dirección, teléfono, fecha de apertura. Luego, </p><p> se encuentra el tipo de cocina, tipo de lugar, medios de pago, servicios, ubicación en el mapa y foto del restaurante. Además, se mostrará la opción siguiente. </p><p>3. El actor llenará los campos mencionados en 4. El sistema verifica que los campos hayan sido el punto 2 con la información correspondiente y llenados y mostrará otra interfaz en la que se soliciten seleccionará la opción Enviar Restaurante. los siguientes datos: nombre de usuario, correo electrónico, contraseña, la contraseña nuevamente y </p><p> los nombres y apellidos de la persona. Finalmente, se mostrará una opción Enviar Solicitud. </p><p>5. El actor llenará los campos mencionados en 6. El sistema muestra un mensaje indicando lo el punto 4 con la información correspondiente y siguiente: Su solicitud ha sido enviada exitosamente. seleccionará la opción Enviar Solicitud. </p><p>Post-condición Flujo principal Una solicitud de nuevo restaurante queda registrada en el sistema </p><p>59 </p><p>Tabla 3.7 Especificación del caso de uso Administrar Información del Restaurante. Administrar Información del Restaurante Id CU-REST-002 Descripción Consiste en que el usuario restaurante pueda administrar la información que </p><p> publicará en el sistema. </p><p>Referencia a FUN-02 Datos lista de requerimientos Paquete Flujo Restaurante Actores Restaurante </p><p>Pre-condición El actor ha iniciado sesión. </p><p>Flujo Principal: “Administrar Información” Acción del Actor Respuesta del Sistema </p><p>1. El actor debe seleccionar la opción 2. El sistema mostrará todos los datos del restaurante Administrar información. registrados durante el paso 2 del caso de uso y mostrará la opción Guardar cambios. </p><p>3. El actor podrá editar todos los datos generales 4. El sistema mostrará el siguiente mensaje: La del restaurante. Asimismo, podrá agregar o información ha sido actualizada. Y se presentará la quitar medios de pago y servicios que brinda. opción Aceptar. Además, podrá cambiar la ubicación del restaurante en el mapa, así como cambiar la imagen del local. Finalmente, seleccionará la opción Guardar cambios. 5. El actor seleccionará la opción Aceptar. 6. El sistema re direccionará hacia la página principal del usuario restaurante. </p><p>Post-condición Flujo principal Se actualizaron los datos del restaurante en </p><p> el sistema </p><p>60 </p><p>3.1.4.3 Diseño Navegacional </p><p>El diseño navegacional en la aplicación corresponde a un conjunto de modelos que se van desarrollando paso a paso, es el esquema o representación gráfica de la aplicación móvil. </p><p>El diseño navegacional describe el contexto en el cual se desenvolverá el usuario, es decir la información a la que tendrá acceso y por donde podrá navegar. El esquema navegacional de la aplicación se observa en la figura 3.8 </p><p>Figura 3.8 Esquema navegacional de la aplicación </p><p>61 </p><p>3.1.4.4 Diseño de Interfaz Abstracta </p><p>Al terminar de desarrollar toda la sección del diseño navegacional se tendrá que especificar las diferentes interfaces del sistema para poder definir así la forma que tendrán los objetos navegacionales en la interfaz. El diagrama de interfaz abstracta se muestra en la Figura 3.9 </p><p>Figura 3.9 Diagrama de interfaz abstracta </p><p>62 </p><p>3.1.4.5 Diagrama de Secuencia de Registro de Georreferenciación de Restaurante </p><p>Se describe a continuación el diagrama de secuencia del caso de uso de georreferenciación de restaurante en que el Administrador, Sistema y Usuario son los actores en el registro de georreferencian de restaurante (ver Figura 3.9) </p><p>Usuario Sistema Administrador</p><p>RegistraGeopuntos(latitud, longitud)</p><p>ModificaGeopuntos(latitud,longitud)</p><p>SolicitarPermisoLocalizacionUsuario()</p><p>DarPermisoLocalizacion()</p><p>MostrarUbicacionActual()</p><p>SolicitarUbicacionRestaurante()</p><p>MostrarUbicacionRestaurante()</p><p>Figura 3.10 Diagrama de Secuencia de georreferenciación de restaurantes </p><p>3.1.4.6 Diagrama de Clases </p><p>En la figura 3.7, se muestra el Diagrama de Clases correspondiente al sistema, el cual sigue la sintaxis dada por UML para poder modelar el software. </p><p>63 </p><p>Estado Rol 1 +Id +Id +Descripcion +Descripcion +Tipo_Estado</p><p>1 1</p><p>* Critica Usuario Comensal +Id * +Id 1 +Valor_Comida +Nombre +Id +Valor_Ambiente +Nombres +Valor_Servicio +Contraseña 1 1 * +Fecha +Apellidos +Precio +Cantidad_Criticas +Comentario +Fecha 1</p><p>1</p><p>Plato</p><p>+Id * +Descripcion +Imagen</p><p>1 *</p><p>Ciudad Restaurante</p><p>+Id +Id 1 +Nombre +Nombre Medio Pago +Direccion +Telefono +Id 1 +Valor_Comida * +Nombre +Valor_Servicio * * +Valor_Ambiente * +Precio_Promedio +Cantidad_Votos Zona +Imagen * +Fecha_Apertura +Id * +Longitud Categoria +Nombre * +Latitud +Contacto_Nombre +Id +Contacto_Email * 1 +Descripcion</p><p>Servicio</p><p>+Id Tipo Cocina +Nombre * * +Id +Nombre</p><p>Figura 3.11 “Diagrama de Clases del Sistema” </p><p>3.1.5 Desarrollo de la Aplicación </p><p>Después de haber realizado el análisis y diseño, en esta sección se desarrollará la aplicación con la estructura y ayuda metódica de la metodología extrema (XP). Se consideran las cuatro variables y los cuatro valores que XP propone </p><p>64 </p><p>3.1.5.1 Las Cuatro Variables </p><p>En el presente proyecto se identificaron las cuatro variables de acuerdo a la metodología, ver Tabla3.8. </p><p>Tabla 3.8 Las cuatro variables de XP Coste El desarrollo de la aplicación móvil no tendrá costo, por ser un proyecto de aporte para impulsar las empresas que se dedican en el ámbito gastronómico en la ciudad de La Paz, y para facilitar el acceso a todos los usuarios. Tiempo El tiempo para el desarrollo de la aplicación móvil está en función a la adición o cambios de requerimientos de los usuarios, al finalizar cada iteración. Calidad En el transcurso de desarrollo de la aplicación móvil, se realizarán pruebas detalladas según el módulo avanzado. Ámbito En cuanto a el ámbito de la aplicación, esta descrito en el apartado de límites y Alcances, en el capítulo I. </p><p>3.1.5.2 Los cuatro valores </p><p>Los valores que se toman en cuenta para el desarrollo de este proyecto son los siguientes: </p><p>Tabla 3.9 Los cuatro valores de XP Comunicación Se fomenta este valor mediante reuniones con la tutor y asesor, que en este caso juega el papel de usuario. Sencillez El diseño de la interfaz en sus diferentes vistas de la aplicación esta expresada de forma sencilla y entendible para facilitar la interacción del usuario según la funcionalidad de los servicios requeridos por este. Retroalimentación Se realizó pruebas de aceptación mediante reuniones para cumplir con los objetivos del proyecto Valentía Valentía para desarrollar una aplicación móvil innovadora con tecnología nueva y capacidad escalable. </p><p>65 </p><p>3.1.5.3 Fase de Exploración </p><p>En esta fase se plantean las historias de usuario de los casos de uso según el formato UML de cada uno de los cuatro módulos. </p><p>3.1.5.3.1 Historias de usuario del módulo registro de restaurantes Tabla 3.10 Historia de usuario, mostrar información de Restaurantes. Historia de Usuario Numero:1 Nombre Historia de Usuario: Mostrar Información de Restaurantes Modificación de Historia de Usuario Numero: Usuario: Sistema Iteración Asignada: Prioridad en Negocio: Alta Puntos Estimados:1 Riesgo de desarrollo: Bajá Puntos Reales: Descripción: Se muestra el despliegue de la información guardada en la base de datos referente a restaurantes Observaciones: Opción disponible mediante la base de Datos </p><p>Tabla 3.11 Tarea, diseñar la estructura de datos para mostrar la información de Restaurantes Trabajo de Ingeniería Numero Tarea:1.1 Numero Historia de Usuario:1 Nombre Tarea: Diseñar la estructura de datos para mostrar la información de restaurantes Usuario: Sistema Iteración Asignada: Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se realiza el diseño de la base de datos con todos los atributos del restaurante </p><p>Tabla 3.12 Tarea, interfaz de salida, para mostrar la información de Restaurantes Trabajo de Ingeniería Numero Tarea:1.2 Numero Historia de Usuario:1 Nombre Tarea: Crear Interfaz para mostrar la información de restaurantes </p><p>66 </p><p>Usuario: Sistema Iteración Asignada: Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se realiza el diseño e implementa la interfaz de salida para el despliegue de restaurantes </p><p>Tabla 3.13 Historia de usuario, mostrar categoría de Restaurante Historia de Usuario Numero:2 Nombre Historia de Usuario: Mostrar categorías de Restaurantes Modificación de Historia de Usuario Numero: Usuario: Sistema Iteración Asignada: Prioridad en Negocio: Alta Puntos Estimados:1/2 Riesgo de desarrollo: Bajá Puntos Reales: Descripción: Se muestra el despliegue de las categorías guardada en la base de datos referente a restaurantes Observaciones: Opción disponible mediante la base de Datos </p><p>Tabla 3.14 Tarea, Diseñar la estructura de datos para mostrar la información de categorías de restaurantes Trabajo de Ingeniería Numero Tarea:2.1 Numero Historia de Usuario:2 Nombre Tarea: Diseñar la estructura de datos para mostrar la información de categorías de restaurantes Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se realiza el diseño de la base de datos con todos atributos de categorías de restaurantes </p><p>67 </p><p>Tabla 3.15 Tarea, diseñar la estructura de datos para mostrar categorías de Restaurantes Trabajo de Ingeniería Numero Tarea:2.2 Numero Historia de Usuario:2 Nombre Tarea: Crear Interfaz para mostrar la información de categorías de restaurantes Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se realiza el diseño e implementación de la interfaz de salida para el despliegue de categoría de restaurantes </p><p>3.1.5.3.2 Historias de usuarios del módulo de usuarios registrados Tabla 3.16 Historia de usuario, mostrar opiniones de los comensales de los Restaurantes Historia de Usuario Numero:3 Nombre Historia de Usuario: Mostrar Opiniones de los comensales de los Restaurante Modificación de Historia de Usuario Numero: Usuario: Sistema Iteración Asignada: Prioridad en Negocio: Alta Puntos Estimados:1 Riesgo de desarrollo: Bajá Puntos Reales: Descripción: Se muestra el despliegue de opiniones guardadas en la base de datos referente a restaurantes Observaciones: Opción disponible mediante la base de Datos </p><p>Tabla 3.17 Tarea, Crear estructura de datos para almacenar opinión del usuario del restaurante Trabajo de Ingeniería Numero Tarea:3.1 Numero Historia de Usuario:3 Nombre Tarea: Crear estructura de datos para almacenar opinión del usuario del restaurante </p><p>68 </p><p>Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se realiza el diseño para que la base de datos almacene las opiniones de los comensales </p><p>Tabla 3.18 Tarea, Crear Interfaz para registro opinión del usuario al restaurante Trabajo de Ingeniería Numero Tarea:3.2 Numero Historia de Usuario:3 Nombre Tarea: Crear Interfaz para registro opinión del usuario al restaurante Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se realiza el diseño e implementa de la interfaz para llenar el formular de opinión </p><p>Tabla 3.19 Tarea, Crear Interfaz para mostrar opiniones de los usuarios de los restaurantes Trabajo de Ingeniería Numero Tarea:3.3 Numero Historia de Usuario:3 Nombre Tarea: Crear Interfaz para mostrar opiniones de los usuarios de los restaurantes Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se diseña e implementa la interfaz para mostrar el listado de opiniones de los usuarios al restaurante </p><p>3.1.5.3.3 Historias de usuario del módulo registro de restaurante Tabla 3.20 Historia de usuario, mostrar ubicación de los Restaurantes Historia de Usuario Numero:4 Nombre Historia de Usuario: Registro de Restaurante Modificación de Historia de Usuario Numero: </p><p>69 </p><p>Usuario: Sistema Iteración Asignada: Prioridad en Negocio: Alta Puntos Estimados:1 Riesgo de desarrollo: Bajá Puntos Reales: Descripción: Se registra a un nuevo restaurante. Observaciones: Opción disponible mediante la base de Datos </p><p>Tabla 3.21 Tarea, Diseñar la estructura de datos para el registro de restaurante Trabajo de Ingeniería Numero Tarea:4.1 Numero Historia de Usuario:4 Nombre Tarea: Diseñar la estructura de datos para el registro de restaurante Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se realiza el diseño de la base de datos con todos los atributos para el registro de restaurante </p><p>Tabla 3.22 Tarea, Crear interfaz para registrar a restaurante. Trabajo de Ingeniería Numero Tarea:4.2 Numero Historia de Usuario:4 Nombre Tarea: Crear interfaz para registrar a restaurante Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se diseña la interfaz para registrar a restaurante. </p><p>3.1.5.3.4 Historias de usuario del módulo georreferenciación de restaurantes Tabla 3.23 Historia de usuario, mostrar ubicación de los Restaurantes Historia de Usuario Numero:5 Nombre Historia de Usuario: Mostrar ubicación de los Restaurantes Modificación de Historia de Usuario Numero: </p><p>70 </p><p>Usuario: Sistema Iteración Asignada: Prioridad en Negocio: Alta Puntos Estimados:1 Riesgo de desarrollo: Bajá Puntos Reales: Descripción: Se muestra la ubicación de restaurantes georreferenciados. Observaciones: Opción disponible mediante la base de Datos </p><p>Tabla 3.24 Tarea, Diseñar la estructura de datos para mostrar ubicación de restaurantes georreferenciados Trabajo de Ingeniería Numero Tarea:5.1 Numero Historia de Usuario:4 Nombre Tarea: Diseñar la estructura de datos para mostrar ubicación de restaurantes georreferenciados Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se realiza el diseño de la base de datos con todos los atributos para la ubicación de restaurantes georreferenciados. </p><p>Tabla 3.25 Tarea, Crear interfaz para mostrar ubicación de los restaurantes georreferenciados Trabajo de Ingeniería Numero Tarea:5.2 Numero Historia de Usuario:4 Nombre Tarea: Crear interfaz para mostrar ubicación de los restaurantes georreferenciados Tipo Tarea: Desarrollo Puntos Estimados:1/2 Fecha Inicio: Fecha Fin: Programador Responsable: Rainer Flores Ibañez Descripción: Se diseña la interfaz para mostrar ubicación de restaurantes georreferenciados. </p><p>71 </p><p>3.1.5.4 Fase de Planificación Después de realizar la fase de exploración con las historias de usuario, se pasa a la fase de planificación para organizar el desarrollo de cada una. </p><p>Estimación de esfuerzos y planificación En esta fase se presenta la estimación de esfuerzos y la planificación del desarrollo de la aplicación. </p><p> Módulo de restaurantes registrados Historias de Usuario Puntos Mostrar información de Restaurantes 1 Mostrar categorías de restaurantes 1/2 </p><p> Módulo de usuarios registrados Historias de Usuario Puntos Mostrar Opiniones de los comensales de 1 los Restaurantes Mostrar Interfaz de registro de usuarios 1 Módulo de registro de restaurante Historias de Usuario Puntos Mostrar interfaz de registro de restaurante 1 </p><p> Módulo de servicios georreferenciación Historias de Usuario Puntos Mostrar ubicación de los Restaurantes 1 </p><p>Tabla de Planificación Luego de realizar las estimaciones, posteriormente se procede a la planificación de cada historia. </p><p>72 </p><p>Tabla 3.26 Planificación en detalle de las historias de usuario Interacciones N° Historias Inicio Fin Observación Primera 1 Mostrar información de 13/09/2016 20/09/2016 Restaurantes 2 Mostrar categorías de 22/09/2016 31/09/2016 restaurantes Segunda 3 Mostrar Opiniones de 1/10/2016 15/10/2016 los comensales al Restaurante 4 Registrar opinión del 17/10/2016 30/102016 usuario al restaurante Tercera 5 Registro de Restaurante 2/11/2016 8/11/2016 Cuarta 6 Mostrar ubicación de 9/11/2016 17/11/2016 los Restaurantes </p><p>3.1.5.5 Fase de Iteración Luego de realizar la estimación de esfuerzos y la planificación de historias de usuarios correspondiente a cada módulo, ahora es momento de iterar cada módulo. Se realizan a continuación las iteraciones correspondientes por módulos. </p><p>3.1.5.5.1 Primera Iteración Historia de Usuario 1: Mostrar información de Restaurantes registrados. Tarea1.1 Diseñar la estructura de datos para mostrar la información de Restaurantes </p><p>Plato</p><p>-Id -Descripcion -Imagen * +addPlato() +eliminarPlato() +editarPlato() +mostrarInforPlato() Restaurante</p><p>-Id 1 -Nombre Medio Pago -Direccion -Telefono -Id -Valor_Comida * -Nombre -Valor_Servicio +addMedioPago() -Valor_Ambiente +eliminarMedioPago() -Precio_Promedio +editarMedioPago() -Cantidad_Votos * -Imagen -Fecha_Apertura -Longitud -Latitud -Contacto_Nombre -Contacto_Email</p><p>+addRestaurant() Tipo Cocina +eliminarRestaurant() +editarRestaurant() * -Id +mostrarInfoRestaurante(datos) -Nombre +mostrarGeorreferenciaLugar() * +addTipoDeCocina() +eliminarTipodeCocina() +editarTipoDeCocina()</p><p>Figura 3.12 Diagrama de clases, información de restaurantes registrados </p><p>73 </p><p>Tarea1.2: Crear interfaz para mostrar la información de restaurantes registrados </p><p>Lista de Restaurantes Detalle de Restaurante </p><p>Figura 3.13 Interfaz de lista de restaurantes y detalle de restaurante </p><p>3.1.5.5.2 Segunda Iteración Historia de Usuario 2: Mostrar categorías de Restaurantes. Tarea2.1 Diseñar la estructura de datos para mostrar categorías de Restaurantes. </p><p>Restaurante</p><p>+Id +Nombre +Direccion +Telefono +Valor_Comida +Valor_Servicio * +Valor_Ambiente +Precio_Promedio Categoria +Cantidad_Votos * +Imagen +Id +Fecha_Apertura +Nombre +Longitud * * +agregarCategoria() +Latitud +mostrarCategoria() +Contacto_Nombre +Contacto_Email</p><p>Figura 3.14 Diagrama de clases, categorías de restaurantes registrados </p><p>74 </p><p>Tarea2.1 Diseñar la Interfaz para mostrar categorías de Restaurantes. </p><p>Lista de Selección de categorías </p><p>Figura 3.15 Interfaz de Categorías </p><p>3.1.5.5.3 Tercera Iteración Historia de Usuario 3: Mostrar categorías de Restaurantes. Tarea3.1 Diseñar la estructura de datos para mostrar categorías de Restaurantes. </p><p>Opinion Usuario Comensal +Id +Id 1 +Valor_Comida +Nombre +Id +Valor_Ambiente +Nombres +Valor_Servicio +Contraseña 1 * +Fecha 1 +Apellidos +Precio +Cantidad_Criticas +Comentario +Fecha</p><p>Figura 3.16 Diagrama de clases, registro de opiniones </p><p>75 </p><p>Tarea3.2 Diseñar la Interfaz para el registro de opiniones. </p><p>Lista de Opiniones de Comensales </p><p>Registro de Opinión </p><p>Figura 3.17 Interfaz de la lista de Opiniones e Interfaz de Registro de Opinión del Restaurante </p><p>Figura 3.18 Interfaz de registro de usuario Restaurante </p><p>76 </p><p>3.1.5.5.4 Cuarta Iteración </p><p>Ubicación del restaurante </p><p>Figura 3.19 Interfaz, mostrar ubicación del Restaurante. </p><p>77 </p><p>CAPÍTULO IV: RESULTADOS </p><p>Después de realizar el desarrollo de la aplicación, se realizaron las pruebas correspondientes y se llegaron a los siguientes resultados. 4.1 Pruebas de desarrollo Se procedió a realizar pruebas considerando cada uno de las historias de usuario por ser unidades que esclarecen los requerimientos y que determinan las principales funcionalidades de la aplicación. Tabla 4.1 Caso de prueba. Historia de Usuario Código Caso de Prueba:1 Nombre Historia de Usuario:1,2,3 Descripción de la Prueba: Evaluación de la Prueba: a. Identificar todos los posibles resultados observables de la historia. • Pantalla con interfaz para desplegar la información de categoría de restaurantes registrados, con su respectiva información. • Pantalla con interfaz con detallada información de un restaurant. b. Identificar los resultados que terminan la historia y los que permiten continuar dentro de la historia c. La historia donde se muestra el despliegue de restaurantes termina al salir de esta pantalla y continua al volver a ingresar </p><p>4.2 Métricas de Calidad En esta apartado se observa la calidad de la aplicación y los procedimientos de seguridad que se siguieron. El objetivo es alcanzar el nivel de calidad necesario y suficiente para evaluar la aplicación y que sea satisfacción a las necesidades del usuario, por ello se evaluó la funcionalidad, eficiencia, fiabilidad y usabilidad. 4.2.1 Funcionalidad Se propone una lista de características que pueden usarse para valorar la calidad del modelo de requerimientos la correspondiente especificación de requerimientos (Pressman, 2005): </p><p>78 </p><p>Tabla 4.2 Requerimientos funcionales Código Descripción del requerimiento Cantidad Administración del sistema FUN-01 El sistema debe permitir que existan tres tipos de usuarios: restaurantes, 1/2 consumidores y administradores. FUN-02 El sistema debe permitir que los Administradores puedan publicar información 1 sobre restaurantes. FUN-03 El sistema debe mostrar la ubicación de los restaurantes georreferenciados. 1 FUN-04 El sistema debe permitir a los usuarios consumidores que critiquen a los 1/2 restaurantes Flujo Restaurantes FUN-05 El sistema debe permitir registrar nuevos restaurantes mediante una interfaz. 1 FUN-06 El sistema debe permitir a los restaurantes administrar su información a publicar 1 FUN-07 El sistema debe permitir que el restaurante registre su ubicación en un mapa. 1 FUN-08 El sistema debe permitir que las páginas de los restaurantes tengan una sección 1/2 de donde se publiquen las calificaciones y críticas de otros consumidores. FUN-09 El sistema debe permitir a cada restaurante poseer su propio catálogo de platos 1/2 y poder administrarlo. Flujo Consumidores FUN-10 El sistema debe permitir el registro de usuarios consumidores mediante una 1 interfaz. FUN-11 El sistema debe permitir a los usuarios consumidores criticar los restaurantes en 1 base a la calidad del servicio, la comida, el ambiente y precio FUN-12 El sistema debe permitir realizar búsquedas con filtros que contengan “nombre 1 del restaurante”, “servicios que brinda”, “tipo de restaurante”, “zona en el que se ubica”, y “tipo de comida. FUN-13 El sistema debe mostrar un mapa en el que se encuentre el restaurante 1 consultado”. FUN-14 El sistema debe permitir a los usuarios consultar restaurantes, su detalle y su 1 ubicación. Seguridad FUN-15 El sistema debe permitir a los distintos usuarios del sistema poder ingresar a este 1 por medio de un inicio de sesión. FUN-16 El sistema debe permitir bloquear el acceso a un usuario en caso este haya 1/2 ingresado datos de autenticación erróneos una cantidad configurable de veces. </p><p>79 </p><p>FUN-17 El sistema debe permitir a cualquier usuario poder cambiar su contraseña. 1/2 Total 14 </p><p>Tabla 4.3 Requerimientos no funcionales Código Descripción del requerimiento Cantidad NFU-01 El sistema debe desarrollarse con herramientas de libre disponibilidad o que posean 1 licencias gratuitas o académicas. NFU-02 El Sistema Operativo en el que se utilice la aplicación deberá tener soporte con 1 mecanismos de geolocalización, tales como Android, Ios, Windows Phone, etc. NFU-03 La aplicación debe ser desarrollada con estándares de programación y una 1 arquitectura que permita que este sea escalable y mantenible en el tiempo. NFU-04 El sistema debe permitir a los administradores dar mantenimiento a los usuarios 1 consumidores para poder darles de baja o reactivarlos. Total 4 </p><p>Tabla 4.4 Historias de usuario Interacciones N° Historias de Usuario Cantidad Primera 1 Mostrar información de 2 Restaurantes 2 Mostrar categorías de 2 restaurantes Segunda 3 Mostrar Opiniones de 3 los comensales al Restaurante 4 Registrar opinión del 2 usuario al restaurante Tercera 5 Registro de Restaurante 3 Cuarta 6 Mostrar ubicación de los 2 Restaurantes Total 14 </p><p>Se supones que existen 푛푒 requerimientos en una especificación y 푛푒푑 = número de especificaciones desarrolladas </p><p>Ecuación (1) 푛푒푑 = 푛푓 + 푛푛푓 </p><p>80 </p><p>Donde nf es el número de requerimientos funcionales, 푛푓 es el número de requerimiento no funcionales. </p><p>Para hallar ne : </p><p>Se tiene 푛푓 = 14 ; 푛푓 =4 </p><p>Reemplazando en ecuación (1): </p><p>푛푒 =14+4 </p><p>푛푒 =18 </p><p>Para hallar 푛푒 en la tabla 4.4 Historias de usuario por iteración, se tiene el listado de las especificaciones desarrolladas, pero es necesario aclarar que los requerimientos no funcionales también fueron abarcados en el transcurso del desarrollo más el requerimiento de kilometraje que no estaba previsto hacerlo con anterioridad pero que fue realizado de kilometraje que no estaba previsto hacerlo con anterioridad pero que fue realizado, por lo tanto se e videncia que el valor obtenido en la totalidad de la especificación desarrollada es la suma de estas cantidades, dado como resultado: </p><p>푛푒 = 19 Para determinar la especificidad (falta de ambigüedad de los requerimientos), (Davis, 1993)sugiere una métrica que se basa en la consistencia de la interpretación de los revisores de cada requisito: </p><p>Ecuación: 푛푒 (2) 푓푠 = 푛푒푑 Remplazando ecuación (2): 18 푓 = = 0.94 푠 19</p><p>81 </p><p>Mientras más cercano a 1 este el valor de fs mayor será la ambigüedad dela especificación. Por lo tanto, el proyecto tiene una funcionalidad del 94% </p><p>4.2.2 Eficiencia Durante la prueba que se realizaron a cada módulo, independientemente de cada uno se pudo observar que los tiempos en función a la respuesta de cada proceso realizado son de 1 a2 segundos, pero en función cabe recalcar que el internet utilizado fue con velocidad 3G, y que el tiempo de respuesta puede variar en función de la velocidad de la conexión en cada momento, sin dejar de lado también al tipo de velocidad que cuente un dispositivo smartphone. </p><p>En cuanto al tiempo que el usuario tardaba al realizar cada tarea, en una primera prueba se consideraron dos usuarios externos, uno de ellos no pudo identificar fácilmente un lugar cercano dado una categoría, para ello existen dos causas probables que las vistas de la interfaz no estaban debidamente ordenadas y poco entendibles, lo cual se mejoró en lo posterior para la segunda prueba, o que el usuario al no estaba familiarizado con la interfaz y le fue difícil identificar determinados iconos y/o pestañas. </p><p>En una segunda prueba, después de la experiencia de prueba piloto en la que se consideró solo dos personas, se realizó una nueva prueba a la cantidad de 25 usuarios exactamente por lo que se pudo observar que en los usuarios hubo un mejor entendimiento y un tiempo menor de búsqueda de un lugar y la facilidad de reconocer la función de cada área. </p><p>Después de realizar una segunda prueba piloto a la aplicación, se puede concluir que los usuarios identifican las tareas que realiza la aplicación en un tiempo considerado optimo y aceptable para el nivel de entendimiento y tiempo en el proceso de realizar las tareas que la aplicación proporciona a sus usuarios. </p><p>82 </p><p>La eficiencia es el grado en que el sistema aplicativo hace optimo el uso de los recursos del sistema, la eficiencia por los tiempos de uso y recursos utilizados, para esta evaluación se utiliza los dados descritos en la Tabla 4.5 </p><p>Tabla 4.5 Factores de eficiencia. Numero Factor de ajuste Valor obtenido 1 Es de respuesta rápida al utilizar sus funciones 94% 2 Tiene rendimiento de acuerdo a los factores que utiliza 97% 3 Responde adecuadamente cuando utiliza sus funciones 93% 4 El tiempo de respuesta a sus consultas es adecuado 91% Promedio 94% </p><p>El sistema obtuvo una eficiencia de 94% </p><p>4.2.3 Fiabilidad Para garantizar la disponibilidad de la aplicación “Manqa”, por el momento el único medio para obtener la aplicación es mediante la Carrera de Informática de la Universidad Mayor de San Andrés, asegurando así su legitimidad y seguridad. Es importante aclarar que también la aplicación es “open source” para lo cual el código está disponible, para poder modificarlo, mejorarlo y distribuirlo libremente. </p><p>4.2.4 Usabilidad Es sabido que la usabilidad viene reflejada en la facilidad de compresión, facilidad de aprendizaje y facilidad de operatibilidad de un software, en este caso el de una aplicación. Para esto se creó un cuestionario que intenta determinar cómo los usuarios están dispuestos a aceptar o rechazar una nueva tecnología, que cobra forma de aplicación. El cuestionario cuenta con dos segmentos: Percepción de usabilidad y percepción de facilidad de uso. El modelo y respuestas a las encuestas del cuestionario se las puede ver en anexos, debido al volumen de las encuestas, solo se consideraron ejemplares del total de 25 personas encuestadas. </p><p>83 </p><p>Análisis de los comentarios de los usuarios De los 25 usuarios que probaron la aplicación se recibieron comentarios más positivos que negativos. Sin embargo, a continuación, se citan solo a aquellos comentarios que no fueron completamente positivos para poder realizar un análisis más interesante: - “Me costó encontrar o identificar la categoría a los restaurantes”. Los nombres en el momento de buscar restaurantes no contemplaban en el esquema general en detalle de todas las listas de los restaurantes, lo cual en un principio causaba desconcierto por parte del usuario. El problema ya fue resuelto y ahora cada información de los restaurantes cuenta con la categoría correspondiente. </p><p>4.2.4.1 Obtención de estadísticas en base al test de usabilidad En base al cuestionario de usabilidad se tienen los siguientes resultados: </p><p>4.2.4.1.1 Utilidad percibida de la aplicación A continuación, se muestran los resultados de las pruebas a los usuarios que se expresan en los siguientes cuadros estadísticos ver Figuras 4.1 y 4.2. </p><p>84 </p><p>Me ahorra tiempo al momento de Me ahorra tiempo al momento de encontrar Lugares gastronomicos en la encontrar Informacion sobre centros ciudad de La Paz gastronomicos en la ciudad de La Paz</p><p>Si No No noto una diferencia Si No No noto una diferencia</p><p>0% 4% 0% 4%</p><p>96% 96%</p><p> a) b) </p><p>Es una aplicacion útil ¿Recomendaria la aplicacion a otras personas? Si No Si No No noto una diferencia 0%</p><p>4% 0% 96%</p><p>100% c) d)</p><p>La experiencia con la aplicacion De acuerdo a su experiencia con la incentiva a conocer mas restaurantes aplicacion, encontro algun problema con los lugares georeferenciados? Si No Posiblemente Si No</p><p>24% 8% 0%</p><p>76% 92%</p><p> e) f)</p><p>Figura 4.1 Cuadros estadísticos según encuesta de usabilidad percibida de la aplicación a) ahorro de tiempo al momento de encontrar Lugares gastronómicos b) ahorro de tiempo al momento de </p><p>85 </p><p> encontrar Información sobre centros gastronómicos c) aplicación útil d) Recomendación de la aplicación a otras personas e) experiencia con la aplicación f) experiencia con la aplicación </p><p>4.2.4.1.2 Facilidad de uso de la aplicación </p><p>La aplicacion es entendible La aplicacion es operable facilmente</p><p>Si No Poco entendible Facil Dificil Muy dificil Muy facil</p><p>0% 0% 8% 0% 12%</p><p>92% 88%</p><p> a) b)</p><p>El tiempo de respuesta de la aplicacion Cuán entendible y amigable es la es optimo? interfaz de la aplicacion para usted?</p><p>Si No Posiblemente 0 - 4 5 - 7 8 - 10</p><p>0% 0% 8%</p><p>36%</p><p>64% 92%</p><p> c) d)</p><p>Figura 4.2 Cuadros estadísticos según facilidad de uso de la aplicación. a) aplicación entendible. b) operable c) tiempo de respuesta d) cuán entendible y amigable la interfaz de la aplicación </p><p>4.3 Controles de seguridad implementación según recomendación de la OWASP Los estándares de seguridad recomendados por OWASP fueron considerados en 10 puntos, mediante los cuales la aplicación fue sometida para realizar cuestiones de seguridad y se llegó a los siguientes resultados: </p><p>86 </p><p> a) Identificación y protección de los datos confidenciales en el dispositivo móvil La aplicación móvil “Manqa”, mantiene seguro los datos confidenciales y privados del usuario ya que el almacenamiento de nombre de usuario, contraseñas y otros datos de mayor relevancia son acogidos en el servidor y en el cache del dispositivo móvil, lo cual provoca mayor seguridad de almacenamiento de información del usuario. b) Manejo de las credenciales de contraseña seguras en el dispositivo En cuanto al manejo de contraseñas, según OWASP sugiere que sí, las contraseñas son almacenadas en el dispositivo, mínimamente debe contar con los mecanismos de cifrado y clave proporcionadas por las tiendas de cada sistema operativo móvil para almacenar de forma segura los datos, pero que al mismo tiempo no deja de correr riesgos, ya que los registros binarios guardados en el dispositivo móvil, son vulnerables a ataques binarios que se pueden descargar fácilmente utilizando ingeniería inversa. Por tal motivo la aplicación propuesta no almacena contraseñas en el dispositivo móvil, sino que es guardado confidencialmente en el servidor respaldado por los propios niveles de seguridad que la misma empresa que desarrollo el servidor controla, en este caso Firebase. c) Garantizar que los datos sensibles estén protegidos en transito Como medida de seguridad, para evitar ataques de suplantación de red, al efectuarse peticiones de información o cualquier tráfico de datos entre la aplicación y el servidor, con cuenta con Firebase, que es una herramienta lo suficientemente robusta para realizar todo el trabajo del back-end por el lado del servidor, y que a su vez realiza y controla que todas las peticiones y envió de datos usen la capa de seguridad SSL. Firebase rechaza cualquier conexión fuera de este contexto. d) Implementación de la autentificación del usuario, autorización y gestión de sesiones correctamente Para la creación de nuevos usuarios de la aplicación “Manqa”, se implementaron las validaciones de los requisitos mínimos que tiene que tener la contraseña del usuario (tener 6 caracteres como mínimo), y validaciones de correos electrónicos correctos, el llenado de espacios vacíos de carácter obligatorio y el control en la duplicación de nombre de usuario y </p><p>87 </p><p> correo electrónico. Sin embargo, ‘‘Manqa” usa el sistema de autenticación proporcionada por parte de Firebase que a su vez es parte de la empresa de Alphabet Inc. realizando así un trabajo transparente y con parámetros de seguridad al momento de la autenticación del usuario. </p><p>Para el inicio de sesión, el usuario puede ingresar llenando los campos (nombre o correto electrónico y contraseña) que aparece como primera vista. e) Mantener la API(s) backend(servicios) y la plataforma(servidor) seguro Con el objetivo de entender mejor el funcionamiento y lógica del back-end ue se utiliza para el desarrollo del proyecto, es necesario explicar y dar un especial enfoque al modo de trabajo que realiza Firebase y su integridad de datos en la nube, lo cual se explica a continuación: Firebase y su integración de datos en la nube Según sus mismos creadores Firebase es un servicio en la nube que nos ofrece un back-end ya desarrollado y avanzado junto con una base de datos en tiempo real, el servicio nos brinda también un servicio de autentificación con nuestras redes sociales y de forma local en su base de datos en la nube. Firebase requiere encriptación SSL con certificados de 2.048-bits para toda la transferencia de datos, ofrece control de acceso granular y soporta esquemas de autenticación personalizados. Todos los datos almacenados en Firebase son replicados y respaldados a múltiples ubicaciones seguras, y Firebase gestiona millones de conexiones concurrentes y miles de millones de operaciones. f) Integración segura con servicios y aplicaciones de terceros La aplicación no usa ningún tipo de servicio de terceros al que se le envíe información del usuario o de los procesos que realice. g) Consentimiento para la recopilación y el uso de datos del usuario “Manqa”, no recopila información adicional sin previa autorización del usuario, no guarda ubicaciones ni acciones que se realice en el dispositivo móvil, dentro o fuera de la aplicación. </p><p>88 </p><p>En el instante en que el usuario ingresa a la aplicación previa autenticación del mismo, se envía una alerta, donde pide la autorización de localización del usuario actual. Esto implica que el usuario al momento de hacer uso de la aplicación, pueda ver su localización en el mapa y como se dijo anteriormente, no se guarda la ubicación del usuario actual. h) Implementación de controles para autorizar acceso a recursos de pago La aplicación no autoriza ni accede a recursos de pago de ninguna manera. i) Garantizar una segura distribución y actualización de la aplicación móvil Por el momento, para obtener la aplicación es mediante la carrera de Informática de la Universidad Mayor de San Andrés. En cuanto a la actualización, “Manqa” se actualizará cuando exista alguna nueva característica para implementar, en caso de alguna observación estará disponible en la parte de Acerca de, la dirección de correo electrónico (rainer,flores64@gmail.com) correspondiente para el feedback. j) Comprobar los errores en tiempo de ejecución Antes de publicar una nueva versión como parte de una actualización de la aplicación “Manqa” se sigue un proceso de testeo mediante pruebas unitarias por módulos. Por lo tanto “Maqa” fue desarrollado mediante la tecnología de Ionic Framework y herramientas open source recomendado por el framework y contando con todo el soporte respectivo. </p><p>4.4 Costo de la aplicación El mercado de las aplicaciones móviles todavía tiene aspectos desconocidos, y el precio de las aplicaciones es uno de ellos. Por otro lado, hay una serie de factores que inciden en el precio de la aplicación, así mismo las características influyen directamente a la hora de calcular cuánto cuesta una aplicación móvil (Yeeply, 2013). </p><p>Es importante basarse en la lógica: “A mayor número de funcionalidad, mayor cantidad en costo” esto quiere decir que cuantas más funcionalidades ofrezca al usuario, más complicado será su desarrollo, por lo que el precio aumentara. </p><p>89 </p><p>Para disipar todas las dudas y saber la forma más aproximada posible acerca de cuánto cuesta una aplicación móvil, se tomó de referencia el cuestionario de presupuestos elaborado y respaldado por Yeeply, donde respondiendo a preguntas sencillas ajustar un precio de mercado muy cercano a la realidad. </p><p>Para calcular un precio aproximado de la aplicación “Manqa”, se prosigue a responder el siguiente cuestionario de presupuestos: </p><p>Tabla 4.6 Cuestionario de presupuestos para ajustes de costos para aplicaciones móviles (Yeeply, 2013) Opciones Pregunta Primera Segunda tercera ¿Qué nivel de calidad Calidad Optima Buena relación No me importa tanto la estas buscando? (calidad precio) calidad ¿Qué tipo de Aplicación Android Aplicación Iphone Aplicación aplicación necesitas? multiplataforma ¿Qué tipo de diseño Interfaz sencilla Interfaz personalizada Interfaz de la web quieres que tenga tu app? ¿Cómo quieres sacar Aplicación gratuita Aplicación de Pago Compras dentro de la beneficio tu app? con publicidad app ¿Tu app necesita un Sí, con redes sociales Sí, con email No sistema de login? y email ¿Tu app tiene que Si No No lo se estas integrada con un sitio web? ¿Los usuarios tienen Si No No lo se sus propios perfiles? ¿Tu app necesita un No No No lo sé todavía panel de administración? ¿Qué idiomas usara tu Un único idioma Bilingüe Multilingüe aplicación? ¿En qué estado se Solo es una idea App en desarrollo App ya desarrollada encuentra tu proyecto? </p><p>Tabla 4.7 Costos según respuestas del cuestionario de presupuestos Pregunta Respuesta Costo $us 1 Buena relación 1000 (calidad/precio) </p><p>90 </p><p>2 Aplicación multiplataforma 1000 3 Interfaz sencilla 900 4 Otros/ No lo sé todavía - 5 Sí, con email 400 6 No - 7 Sí 800 8 Sí 1000 9 Un único idioma 800 10 App ya desarrollada - Total=10 Total=5900 </p><p>Se considera de acuerdo al ajuste de precios según al tipo de aplicación con los siguientes rangos: Rango Aplicaciones simples 1.500 ≤ 푥 ≤ 5.000 Aplicaciones que necesiten cargar bases de datos 5.000 ≤ 푥 ≤ 35.000 Aplicaciones basadas en hardware especifico 2.000 ≤ 푥 ≤ 35.000 Aplicaciones hechas a medida 5.000 ≤ 푥 ≤ 100.000 Aplicaciones para los juegos móviles 7.500 ≤ 푥 ≤ 100.000 </p><p>Nuestra variable se encuentra dentro de los rangos: </p><p>5.000 ≤ 푥 ≤ 35.000 5.000 ≤ 푥 ≤ 100.000 </p><p>Análisis y resultado del costo de la aplicación De acuerdo a la comparación de rangos que se ajustan al tipo de aplicación, el costo de la aplicación propuesta se encuentra dentro del rango de aplicaciones hechas a medida y que requieran una fuente externa (servidor). Por lo tanto, la aplicación Manqa tiene un costo aproximado de 5900$us, que va implementado desde su diseño hasta la fase de publicación. </p><p>91 </p><p>CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES </p><p>5.1 Conclusiones </p><p>Se ha desarrollado una aplicación móvil para la georreferenciación de restaurantes, que sirva como guía para la ciudad de La Paz, mediante el uso de nuevas tecnologías como los servicios de geolocalización e integración de datos en la nube, dando como resultado un sistema aplicativo intuitivo y fácil de comprender, dando cumplimiento al objetivo principal de la presente tesis. </p><p>Respecto a los objetivos secundarios se desarrolló e implemento el módulo de georreferenciación de lugares gastronómicos en la ciudad de La Paz, mediante el uso de los servicios de google maps y la identificación de geopuntos, con esto se logró proporcionar a los usuarios una vista interactiva de cada uno de los lugares georreferenciados. </p><p>Así, se logró crear un espacio en el que se mantenía un registro de restaurantes y comensales, en el cual estos últimos son capaces de encontrar los locales que se adecúen mejor a sus necesidades y criticarlos para generar información neutral con respecto a los servicios que bridan. </p><p>Respecto a la metodología utilizada para el desarrollo de la aplicación, se realizaron y cumplieron cada una de las fases de la metodología ágil (XP) que fueron de mucha ayuda para poder completar de manera ordenada y muy bien estructurada metódicamente el desarrollo de la aplicación, al mismo tiempo se realizaron las pruebas pertinentes a cada módulo entre ellas las pruebas de desarrollo considerando cada uno de las historias de usuario correspondientes a su módulo, finalmente se puede concluir que esta metodología fue de fácil comprensión y de mucha utilidad y al mismo agilizó el proceso de desarrollo de la aplicación, por consiguiente se da cumplimiento al objetivo secundario. </p><p>92 </p><p>5.2 Recomendaciones </p><p>La aplicación ayudará a encontrar y visualizar en el mapa restaurantes de interés con su respectiva etiqueta, pero no indicará rutas de llegada, lo cual sería aconsejable integrar a la aplicación para aumentar más funcionalidad al mismo. </p><p>Considerar que en el caso de la carga de los geopuntos para la georreferenciación de lugares no dependa en su totalidad de una conexión a internet, sino que esos datos sean cargados offline en caso de no contar con ningún tipo de conexión. </p><p>Por otra parte, la presencia de por lo menos dos idiomas que ejecuten la aplicación es recomendable por ser el inglés un idioma general a nivel mundial. Po lo tanto se recomienda que la aplicación contenga también en futuras actualizaciones diccionarios de recursos para idiomas oficiales dentro el departamento de La Paz. </p><p>93 </p><p>BIBLIOGRAFÍA </p><p>Agrawal, R. (2008). UC BERKELEY DATABASE GROUP. Recuperado el Noviembre de 2014, de The Claremont report on database research. Amate, C. (septiembre de 2014). ThinkBig. Recuperado el Diciembre de 2014, de Conoce (bien) los principales sistemas operativos móviles. Avila, N. (Junio de 2011). Platzi. Recuperado el Octubre de 2014, de maestrosdelweb.: http://www.maestrosdelweb.com/guia-mapas-geolocalizacion-moviles/ Berry, J. (1996). Beyond Mapping: Concepts, Algorithms, and Issues in GIS. Wiley. Recuperado el abril de 2014 Davis, A. M. (1993). Software requirements: objects, functions, and states. Prentice-Hall, Inc. Recuperado el Octubre de 2015 Duclos, C. (11 de Septiembre de 2010). Product Forums. Recuperado el 19 de Marzo de 2014, de Product Formuns Google: https://productforums.google.com/forum/#!forum/maps-es/SOwHzdsSljO ecma. (Junio de 2015). standard ECMA-262. Recuperado el Octubre de 2015, de ECMAScript 2015 Lenguage Specification: http://www.ecma- international.org/news/Publication%20of%20ECMA-262%206th%20edition.htm Educators, t. S. (2013). Pedagogy in Action. Recuperado el Noviembre de 2014, de What is Google earth?: http://serc.carleton.edu/sp/library/google_earth/what.html ENISA. (25 de Noviembre de 2011). Smartphone Secure Development Guidelines. Recuperado el Noviembre de 2015, de enisa: http://www.enisa.europa.eu/act/cert/ Google. (2014). google. Recuperado el noviembre de 2014, de Google maps: https://developers.google.com/maps/documentation Green, B. (2015). AngularJs. Recuperado el Enero de 2015, de AngularJs: https://angularjs.org/ IBM. (2012). Native, web or hybrid mobile-app development. IBM Worklight. Recuperado el Octubre de 2015, de ftp://public.dhe.ibm.com/software/pdf/mobile- enterprise/WSW14182USEN.pdf </p><p>94 </p><p>Intel. (2014). Intel Developer Zone. Recuperado el Junio de 2015, de Intel® XDK: https://software.intel.com/en-us/intel-xdk Ionic, F. (2013). Ionic Framework. Recuperado el Enero de 2015, de Ionic Framework: http://ionicframework.com/docs/ ITNews. (2013). Salesforce. Recuperado el Diciembre de 2014, de ¿Qué es Cloud Computing?: http://www.itnews.ec/marco/000035.aspx Larman, C. (2003). UML y patrones. Pearson Educación. Recuperado el Noviembre de 2014 Llamas, R., & Reith, R. (2014). IDC. Recuperado el Enero de 2015, de idc.com: http://www.idc.com/prodserv/smartphone-os-market-share.jsp MSDN, M. D. (2014). Model-View-Controller. Obtenido de https://msdn.microsoft.com/en-us/library/ff649643.aspx OpenStreetMap. (2014). OpenStreetMap. Recuperado el Octubre de 2014, de OpenStreetMap: https://www.openstreetmap.org OWASP. (2008). OWASP. Guía de Pruebas OWASP. Recuperado el Octubre de 2015, de http://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3 .0.pdf Pressman, R. S. (2005). Ingenieria de Software. McGraw-Hill. Recuperado el 2014 Razón, L. (2014). La expansión de la clase media alimenta el negocio de la comida. Obtenido de La Razón: http://www.la- razon.com/index.php?_url=/suplementos/financiero/expansion-media-alimenta- negocio-comida_0_1977402368.html Robledo Fernández, D. (2014). Desarrollo de aplicaciones para Android II. Recuperado el Junio de 2015 Schmuller, J. (2001). Aprendiendo UML en 24 horas. Pearson Educación. Recuperado el Agosto de 2014 Solís, C. (2015). Manual del Guerrero: AngularJS. Recuperado el Junio de 2015, de http://www.manualdelguerrero.com techopedia. (s.f.). techopedia. Obtenido de https://www.techopedia.com/definition/23586/mobile-device </p><p>95 </p><p> w3c. (abril de 2014). css3. Recuperado el mayo de 2014, de CSS3current work: http://www.w3.org/Style/CSS/ w3c. (Ocutubre de 2014). html5. Recuperado el Agosto de 2014, de html5: http://www.w3.org/TR/html5/ Wells, D. (2009). extremeprogramming. Recuperado el septiembre de 2014, de extremeprogramming: http://www.extremeprogramming.org/ Yeeply. (2013). ¿Cuánto cuesta una aplicación móvil? . Obtenido de yeeply: https://www.yeeply.com/blog/cuanto-cuesta-una-aplicacion-movi/ </p><p>96 </p><p>ANEXOS </p><p>97 </p>
</div>
</article>
</div>
</div>
</div>
<script type="text/javascript" async crossorigin="anonymous" src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-8519364510543070"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.1/jquery.min.js" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
<script>
var docId = 'c209c393c10c21c3323a322d72ca91cb';
var endPage = 1;
var totalPage = 109;
var pfLoading = false;
window.addEventListener('scroll', function () {
if (pfLoading) return;
var $now = $('.article-imgview .pf').eq(endPage - 1);
if (document.documentElement.scrollTop + $(window).height() > $now.offset().top) {
pfLoading = true;
endPage++;
if (endPage > totalPage) return;
var imgEle = new Image();
var imgsrc = "//data.docslib.org/img/c209c393c10c21c3323a322d72ca91cb-" + endPage + (endPage > 3 ? ".jpg" : ".webp");
imgEle.src = imgsrc;
var $imgLoad = $('<div class="pf" id="pf' + endPage + '"><img src="/loading.gif"></div>');
$('.article-imgview').append($imgLoad);
imgEle.addEventListener('load', function () {
$imgLoad.find('img').attr('src', imgsrc);
pfLoading = false
});
if (endPage < 7) {
adcall('pf' + endPage);
}
}
}, { passive: true });
</script>
<script>
var sc_project = 11552861;
var sc_invisible = 1;
var sc_security = "b956b151";
</script>
<script src="https://www.statcounter.com/counter/counter.js" async></script>
</html><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script> 