MARCO TEÓRICO Ingeniería de Software Móvil La inge ingeni nier era a de soft softwa ware re móvi móvill es una una disc discip iplilina na que que incl incluy uye e meto metodo dolo logí gías as y técn técnic icas as para ara gene genera rarr apli apliccacio acion nes móvi móvile less de form forma a corr corre ecta, cta, optim ptimiz iza ada y que que cump umpla con los los requ requer erim imie ien ntos tos de desar esarro rollllo o pedid edido os por por el clien liente te.. Esta Esta inge ingeni nier ería ía cuent uenta a con con dive iversas etapas o pasos para concretar el proyecto, to, están incluidas el análisis de req requeri uerim mient iento os, la espe especi cifi ficcació ación n, la arqui rquite tecctura tura,, la prog progra rama maci ción ón,, las las prueb ruebas as,, la documentación y el mantenimiento. (Agudelo, 2011) La inge ingen nierí iería a de softw oftwa are móvi móvill es igu igual a la de la ing ingenie enierí ría a de mic microc rocomp omputad utador ora as pero en un tamaño reducido, donde se tiene una nueva cultura una nueva forma rma de realizar el proyecto donde se establece de primera vez las limitaciones y las características del dispositivo o de los dispositivos a apuntar como plataforma a lleg llegar ar y así así gene genera rarr los los requ requer erim imie ient ntos os nece necesa sari rios os para para real realiz izar ar el proy proyec ecto to y obte obtene ner r soluciones viables. (GAVF, 2010)
Metodología de desarrollo de aplicaciones móviles – Mobile-D
En el mundo del desarrollo de software existen muchos métodos de desarrollo, cada uno con sus puntos fuertes y sus puntos débiles. En el caso del desarrollo de aplicaciones móviles sucede lo mismo. Una de las características importantes de la gran mayoría de los desarrollos móviles es su corta duración. Esto se debe a factores como la gran competencia en el sector, los cambios en el mismo con la aparición, casi constante, de novedades tanto software como hardware, el hecho de que muchas aplicaciones nacen con un desarrollo precoz en forma de prototipo y van evolucionando después o incluso la simplicidad de las aplicaciones, que no requieren grandes desarrollos. Esta suele ser, salvo algunas excepciones, la norma de los desarrollos de aplicaciones para dispositivos móviles.
Mobile-D
El método Mobile-D es una metodología ágil que está pensada para un equipo con un número menor o igual a 10 desarrolladores y se orienta en superar las dificultades implicadas en el desarrollo de aplicaciones móviles en un tiempo corto. Se desarrolló junto con un proyecto finlandés en el 2004. Fue realizado, principalmente, por investigadores de la VIT 1 y, a pesar de que es un método antiguo, sigue en vigor (se está utilizando en proyectos de éxito y está basado en técnicas que funcionan). El objetivo es conseguir ciclos de desarrollos muy rápidos en equipos muy pequeños (como se dijo no más de diez desarrolladores) trabajando en un mismo espacio físico. Según este método, trabajando de esa manera se deben conseguir productos totalmente funcionales en menos de diez semanas. Se trata de método basado en soluciones conocidas y consolidadas: Extreme Programming (XP), Crystal Methodologies y Rational Unified Process (RUP), XP para las
prácticas de desarrollo, Crystal para escalar los métodos y RUP como base en el diseño del ciclo de vida. El ciclo de vida de Mobile-D se divide en cinco fases: exploración, inicialización, producción, estabilización y prueba
En la figura 1, se presenta las fases de la Metodología Mobile- D.
1 VIT: Instituto de investigación Finlandés
Fases 1. Exploración
La fase de exploración tiene como propósito la planificación y el establecimiento del inicio del proyecto. La fase de Exploración puede desvincularse oportunamente de las fases posteriores y también se superpone con la fase de iteración 0. La fase de Exploración es una fase importante que sienta las bases para una implementación controlada del desarrollo del producto software, por ejemplo, las cuestiones relacionadas con la arquitectura del producto, el proceso de desarrollo de software y la selección del ámbito. Los diferentes grupos de interés (stakeholders) son necesarios para proporcionar su conocimiento en la fase de Exploración.
2. Inicialización
El propósito de la fase de Inicialización es permitir el éxito de las próximas etapas del proyecto mediante la preparación y verificación de todos los temas críticos del desarrollo, de modo que todos ellos estén en plena disposición al final de la fase, para luego realizar la implementación de los requisitos seleccionados por el cliente. Además se preparan todos los recursos físicos, tecnológicos y de comunicaciones para las actividades de producción.
Como se dijo, en esta fase se asegura el éxito del proyecto, ya que se realiza un estudio sobre todos los datos obtenidos en la fase anterior, para que de esta manera se escoja de manera correcta, las herramientas adecuadas para proceder a instalar, configurar y probar los ambientes tanto físicos como técnicos, los recursos que contribuyan en el proceso de desarrollo de la aplicación tomando en cuenta las correctas librerías a utilizar, sin dejar a un lado la verificación de la compatibilidad entre software y hardware que se necesitan para la elaboración de la misma. 3. Producción, Desarrollo o Producto
El propósito de la fase de Producción es implementar la funcionalidad requerida en el producto, mediante la aplicación del ciclo de desarrollo iterativo e incremental. El desarrollo basado en pruebas es utilizado para implementar las funcionalidades. Durante esta fase,se implementa la funcionalidad de la aplicación, tomando en cuenta los requerimientos del cliente, y con la utilización de ciclos de desarrollo iterativos e incrementales, permitir la mejora continua del producto. El desarrollo de esta fase se lo realiza mediante etapas representadas en día de planificación en donde se ejecuta los test de aceptación, día de trabajo en donde se desarrolla el proyecto con su debida documentación y por último el día de entrega, en el cual se procede al llenado de la lista de resumen de deficiencias. 4. Estabilización
El propósito de la fase de Estabilización es asegurar la calidad de la ejecución del proyecto. En esta etapa se asegura la calidad de la implementación o unión de todos los módulos del proyecto con el objetivo de obtener un solo producto. Para ello, se lo realiza de la misma manera que la fase de producción, basándose en el desarrollo mediante las 3 etapas: día de planificacion, día de trabajo y día de entrega. La documentación en esta fase es similar a la fase de desarrollo con la diferencia que en el día de planificación se debe llenar el primer taller post iteración, cuyo objetivo es documentar la resolución de las deficiencias obtenidas en la iteración anterior.
5. Pruebas y Corrección del sistema
El propósito de la fase de pruebas y corrección del sistema es determinar si el sistema producido implementa la funcionalidad definida por el cliente de manera correcta, proporcionando al equipo encargado del proyecto, la realimentación de la funcionalidad del sistema y la corrección de los defectos encontrados. En esta última fase, se comienza una exploración de deficiencias en el software. Se realiza la planificación, trabajo y entrega del software completo. De igual manera que la fase anterior, se realiza el un taller post iteración cuyo objetivo es corregir las últimas deficiencias para que el producto cumpla correctamente con las funciones principales que el cliente las estableció al inicio del proyecto. Elementos
Existen 9 elementos principales involucrados en las diferentes prácticas en el transcurso del ciclo de desarrollo: ● Ajuste y enfoque de fases: los proyectos se llevan a cabo en iteraciones donde cada una comienza con un día de planificación. ● Línea de arquitectura: este enfoque es utilizado junto con los patrones de arquitectura y modelo ágil. ● Desarrollo basado en pruebas: el enfoque de pruebas-primero es utilizado junto con casos de prueba automatizadas. ● Integración continua: las prácticas de Software Configuration Manager (SCM) se aplican a través de múltiples medios. ● Programación en pares: la codificación, pruebas y refactorización se lleva a cabo en pares. ● Métricas: pocas métricas se recogen con rigurosidad y se utilizan con fines de mejorar la retroalimentación y el proceso de desarrollo. ● Cliente externo: el cliente participa en las jornadas de planificación y liberación. ● Enfoque centrado en el usuario: se hace hincapié en la identificación y el cumplimiento de necesidades del usuario final. Estos elementos son prácticas ya establecidas en metodologías ágiles, con la inclusión de la línea de arquitectura, que se usa para capturar el conocimiento de una organización de soluciones arquitectónicas, tanto de fuentes internas y externas, y usar estas soluciones cuando sea necesario.
Aplicación Móvil App Bibliotecas de San Juan
Se desea generar una aplicación móvil que permita la visualización de la TOTALIDAD de las bibliotecas que se encuentran en el territorio de San Juan (mapa). Entre los requerimientos se encuentra: a) Aplicación nativa Android. b) Plataforma de desarrollo AppInventor (MIT) c) Uso de Google Maps o similar para despliegue del mapa. d) Uso de Google Fusion Tables como servidor de datos. e) Posibilidad de ABM desde el móvil, con permiso de usuario administrador. ABM On Line / Off Line f) Los atributos a almacenar en la tabla Fusion Table asociada, serán .... (los que se usan en la Encuesta del Proyecto) g) Posibilidad de vistas filtradas (ej. Solo las bibliotecas escolares, solo las que poseen bibliotecarios titulados, etc.) h) Uso de Google Street para “calcular ruta”. 1. Desarrollo de la Solución
El desarrollo del prototipo de la App Bibliotecas de San Juan con la metodología Mobile-D, la cual se compone de 5 fases como se observa en la Figura 2: Exploración, Inicialización, Producto, Estabilización y Pruebas del sistema o Control de Versiones. En la figura 2, se presenta las fases de la metodología Mobile-D la cual es la que se va aplicar.
1.1. Fase 1: Exploración
1.1.1. Establecimiento de Stakeholders
En esta actividad se definió a los involucrados del Proyecto y se identificó sus tareas, roles y responsabilidades: Líder de Proyecto: 1 Jefe de Proyecto Luis Olguin Equipo de desarrollo: 1 Analista de Requerimientos (Isabel) 2 Analista Programador
(Valeria y Sandra) 2 Analista de Pruebas (Valeria y Sandra) Usuarios de la Aplicación: ciudadano residente en Argentina y todo el mundo. Sponsor: Universidad Nacional de San Juan. En reunión con todos ellos se definió la propuesta del producto, el cual es el desarrollo de una aplicación nativa Android llamada “Bibliotecas de San Juan” utilizando una plataforma de desarrollo AppInventor (MIT). 1.1.2. Definición de Alcance
En esta actividad se determinó los requisitos previos, así como los objetivos y el alcance del producto en base al tiempo de duración del proyecto. Requisitos Previos:
● ● ● ● ●
La aplicación funciona con acceso a internet. Uso de Google Fushion Tables 1 SmartPhones con Sistema operativo Android en versión 3.0 o superior. Uso de Google Maps o similar. La aplicación es desarrollada para el sistema operativo Android
Objetivos:
● Los datos de la aplicación deberán estar almacenados en una hoja de cálculo llamada Fushion Table, la cual está asociada a Google Maps. Los mismos son recolectados desde las encuestas online realizadas a las bibliotecas de San Juan en las que se desempeña un egresado/alumno del ISBM (exportación TXT desde la plataforma EncuestaFacil). ● Permitir la carga de datos manualmente por un administrador, utilizando la función de registrar nuevos datos (CRUD) desde el móvil con permiso de usuario administrador. ● El ALTA debe ser posible de ejecutar Off Line, y posteriormente “gestionar la actualización” . ● Poder realizar búsquedas a través de la elección de distintos filtros de búsqueda( localidad, distancia, tipo: escolares, legislativas, popular etc.). ● Obtener los atributos de la biblioteca buscada al dar click en la misma. ● Tener la opción de geolocalización de las bibliotecas de San Juan.
● Cada una de las bibliotecas deben mostrar su nombre que la identifica en el Mapa. ● Tener datos referentes a la totalidad de bibliotecas del territorio de San Juan. ● La aplicación deberá estar almacenada en la tienda de descarga de aplicaciones que ofrece Google llamada Play Store.
Alcance:
Prototipo funcional de una App Android que permite la visualización de la TOTALIDAD de las bibliotecas que se encuentran en el territorio de San Juan Argentina (a través de un mapa) haciendo uso de Google Maps o similar para despliegue del mismo, y obtener de esta manera los atributos de la biblioteca seleccionada o buscada. Para realizar la búsqueda se podrá utilizar distintos filtros (localidad, distancia, tipo de biblioteca entre otros). Para esto. se consultará automáticamente la hoja de cálculo “Fushion Tables”de Google Maps.
1.2. Fase 2: Inicialización
1.2.1 Definición de las partes interesadas
● Bibliotecas de San Juan: Son una de las entidades beneficiarias del proyecto ya que con su aparición en la app , captarán más usuarios. Muestran su interés aportando información para el desarrollo de la app, la misma es recolectada a través de encuestas online realizadas por miembros del equipo del proyecto, esta información será recolectada y procesada para su utilización en la app a desarrollar. ● Usuarios de la ciudad de San Juan: son los ciudadanos o turistas que se encuentran en la ciudad de San Juan que carecen de información sobre las bibliotecas y su ubicación, que existen dentro de la zona urbana de San Juan.
1.2.2. Recolección de Requerimientos
Para recolectar los requerimientos iniciales se contó con la participación de los miembros del equipo de trabajo y se generó una lista con los más importantes. 1.2.3. Requerimientos Iniciales
Los requerimientos iniciales que se pudieron identificar son los siguientes: -
Registrar una nueva biblioteca
-
Modificar una biblioteca Eliminar una biblioteca Mostrar bibliotecas aplicando filtro distintos filtros de búsqueda Mostrar atributos de una biblioteca seleccionada. Login Usuario 1.2.4. Preparación del Proyecto
El objetivo de esta etapa es definir los recursos físicos y tecnológicos necesarios para el desarrollo del proyecto; también se debe considerar la capacitación del equipo de desarrollo, de ser necesario. En esta etapa es importante la participación de todos los miembros del proyecto.
Entorno técnico y físico del proyecto ● ● ● ● ● ●
Tecnología: Android Lenguaje de Programación: Java usando AppInventor MIT Librerías Java: jdk 7.0 IDE: AppInventor 2 Sistema Operativo: Android versión 3.0 o superior 2 Laptops con procesador I3/I5, 4 GB de RAM y con espacio mínimo disponible en Disco de 10GB. ● Metodología de Desarrollo: Mobile-D Para comenzar a realizar este proyecto, fue necesario establecer tres partes principales: 1- Preparación del ambiente: Esta tarea involucra directamente a los desarrolladores de
software y permite establecer el ambiente físico y técnico en el cual se llevará a cabo el desarrollo. A continuación se detallan los dos ambientes necesarios para la realización de este proyecto. Consta en dejar claro que herramientas se va a utilizar en el transcurso del proyecto de manera que, al iniciar el desarrollo del mismo, todo transcurra sin ninguna novedad y mucho menos con retrasos. Para ello se instaló lo siguiente: ● El lenguaje de programación para dispositivos móviles Android Studio, con las librerías y plataformas necesarias para el funcionamiento correcto de las APIs de Google: ➢
● ● ● ● ● ●
Plataformas
Android 4.0 (IceCreamSandwich). Android 4.4 (KitKat). Android 5.0 (Lollipop). Android 6.0 (Marshmallow). Android 7.0 (Nougat). Android 7.1.1 (Nougat).
Librerías:
● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ➢ ➢
➢
➢
Android SDK Build-Tools Android Auto API Simulators V. 1.0.0 Android Auto Desktop Head Unit emulator, rev 1.1 V. 1.1.0 Android SDK Platform-Tools V. 25.0.3 Android SDK Build-Tools V. 25.2.5 Documentation for Android SDK V.1 GPU Debugging tools V.1.0.3 GPU Debugging tools V.3.1.0 Google Play APK Expansión Library V. 1 Google Play Billing Library, rev 5 V. 5.0.0 Google Play Licensing Library V.1 Google Play service V. 38 Google USB Driver, rev 11 V.11.0.0 Google Web Driver, rev 2 V.2.0.0 Intel x86 Emulator Accelerator (HAXM installer) V. 6.0.5 Android Support Repository V. 43.0.0 Google Repository V.43 Generación del Token necesario para acceder a Fushion Tables Generación del Token necesario para el acceso al IdeI de la aplicación App Inventor 2 Se preparó el lenguaje de programación Visual Studio 2015 para la creación de Web Service con su respectiva librería ODBC (Open DataBase Connectivity) para que se pueda conectar con una base de datos Oracle.para la creación de Web Service con su respectiva librería ODBC (Open DataBase Connectivity) para que se pueda conectar con una base de datos Oracle. Creación de nuestra hoja de cálculo Fushion Table, para la adecuada administración de la información
Esta tarea garantiza que el equipo de desarrollo tenga la capacitación oportuna y necesaria para atender necesidades específicas del proyecto. El entrenamiento o capacitación puede ser enfocada a resolver vacíos en los procesos del ciclo de desarrollo o temas técnicos como implementación de nuevas herramientas o métodos, así como sus actualizaciones. 2- Capacitaciones: en cuestión al conocimiento que se debe tener para utilizar las
diferentes herramientas expuestas anteriormente, se realizó una capacitación técnica al equipo de desarrollo sobre la tecnología de desarrollo móvil con la plataforma AppInventor (MIT). 3- Plan de Comunicación con los Interesados: en cuanto a la comunicación con los interesados,se solicitó a las distintas bibliotecas de San Juan completar una encuesta online para la obtención de datos fundamentales que dará origen a su aparición y ubicación en el mapa final de búsqueda.
1.2.2. Planificación de Fases
Para completar la planificación inicial se entrega la primera planificación de fases con las iteraciones respectivas. Fase
Iteración
Descripción
Exploración
Iteración 0
Establecimiento del proyecto, entrenamiento.
Inicialización
Iteración 0
Análisis de requerimientos iniciales.
Producción
Iteración 1
Implementación de la funcionalidad de registro de usuarios. Mejoramiento y actualización de historias de usuario. Definición de las interfaces. Generación de las pruebas de aceptación.
Iteración 2
Implementación de la funcionalidad de Registrar Biblioteca. Mejoramiento y actualización de historias de usuario. Definición de las interfaces. Generación de las pruebas de aceptación.
Iteración 3
Implementación de la funcionalidad de Modificar Biblioteca. Mejoramiento y actualización de historias de usuario. Definición de las interfaces. Generación de las pruebas de aceptación.
Iteración 4
Implementación de la funcionalidad de Eliminar Biblioteca. Mejoramiento y
actualización de historias de usuario. Definición de las interfaces. Generación de las pruebas de aceptación.
Estabilización
Iteración 5
Implementación de la funcionalidad de Mostrar Bibliotecas aplicando distintos filtros de búsquedas. Mejoramiento y actualización de historias de usuario. Definición de las interfaces. Generación de las pruebas de aceptación.
Iteración 6
Implementación de la funcionalidad de Mostrar atributos de una biblioteca al seleccionarla. Mejoramiento y actualización de historias de usuario. Definición de las interfaces. Generación de las pruebas de aceptación.
Iteración 7
Refactorización de la funcionalidad de registro de usuarios. Establecimiento de las interfaces definitivas. Aplicación de las pruebas de aceptación
Iteración 8
Refactorización de la funcionalidad de registro de biblioteca. Establecimiento de las interfaces definitivas. Aplicación de las pruebas de aceptación
Iteración 8
Refactorización de la funcionalidad de modificar
una biblioteca. Establecimiento de las interfaces definitivas. Aplicación de las pruebas de aceptación
Prueba
Iteración 9
Refactorización de la funcionalidad de eliminar una biblioteca. Establecimiento de las interfaces definitivas. Aplicación de las pruebas de aceptación
Iteración 10
Refactorización de la funcionalidad de mostrar una biblioteca aplicando distintos filtros de búsqueda. Establecimiento de las interfaces definitivas. Aplicación de las pruebas de aceptación
Iteración 11
Refactorización de la funcionalidad de mostrar atributos de una biblioteca al seleccionarla. Establecimiento de las interfaces definitivas. Aplicación de las pruebas de aceptación
Iteración 12
Se evalúan las pruebas y se analizan los resultados obtenidos.
1.2.3. Explicación al equipo de desarrollo el producto a desarrollar en base a los requerimientos definidos
Identificador
F01
Nombre
Registrar una nueva biblioteca
Tipo
funcional
Prioridad
Alta
Necesidad
si
Verificable
si
Descripción: El usuario administrador de la App debe poder entrar a la misma de modo
off-line o on-line y poder cargar una nueva biblioteca y esta debe ser almacenada en la tabla de excel de Fushion Tablet de Google y mostrarse automáticamente en el mapa de google.
Identificador
F02
Nombre
Modificar una biblioteca
Tipo
funcional
Prioridad
Alta
Necesidad
si
Verificable
si
Descripción: El usuario administrador de la App debe poder entrar a la misma de modo
off-line o on-line y poder modificar una biblioteca que se encuentre ya registrada y esta debe ser almacenada en la tabla de excel de Fushion Tablet de Google y mostrarse automáticamente en el mapa de google, con sus valores actualizados.
Identificador
F03
Nombre
Eliminar una biblioteca
Tipo
funcional
Prioridad
Alta
Necesidad
si
Verificable
si
Descripción: El usuario administrador de la App debe poder entrar a la misma de modo
off-line o on-line y poder eliminar una biblioteca que se encuentre ya registrada y esta debe ser eliminada de la tabla de excel de Fushion Tablet de Google y el mapa debe actualizarse no mostrandola. Identificador
Tipo
F04
funcional
Nombre
Mostrar una bibliotecas aplicando filtros de búsqueda
Prioridad
Alta
Necesidad
si
Verificable
si
Descripción: Los usuarios de la App deben poder entrar a la misma de modo on-line
desde su celular y poder buscar bibliotecas aplicando distintos filtros de busqueda ( Solo las bibliotecas escolares, solo las que poseen bibliotecarios titulados, por localidad etc. ) y las mismas deben aparecer en el mapa.
Identificador
F05
Nombre
Mostrar atributos de una biblioteca seleccionada
Tipo
funcional
Prioridad
Alta
Necesidad
si
Verificable
si
Descripción: Los usuarios de la App deben poder entrar a la misma de modo on-line
desde su celular y al seleccionar una bibliotecas en el mapa, esta debe desplegar un menú con sus atributos más importantes. ( ubicación, tipo etc.)
1.3. Fase 3: Fase de Desarrollo ( historias de usuario y porototipos)
Esta fase consta de varias tareas, de las cuales dos son las más importantes: ● Documentación de los avances que se van realizando. ● La comunicación con los interesados mediante reuniones exponiendo los avances de acuerdo a los requisitos dados.
1.3.1 Modelo de Datos
En este punto se muestra el diseño de la tabla de Fushion tablet , la cual será nuestra base de datos, en donde la App realizará las consultas.
