MARCO TEÓRICO

Ingeniería de Software Móvil

La ingeniera de software móvil es una disciplina que incluye metodologías y técnicas

para generar aplicaciones móviles de forma correcta, optimizada y que cumpla con
los requerimientos de desarrollo pedidos por el cliente. Esta ingeniería cuenta con
diversas etapas o pasos para concretar el proyecto, están incluidas el análisis de
requerimientos, la especificación, la arquitectura, la programación, las pruebas, la
documentación y el mantenimiento. (Agudelo, 2011)
La ingeniería de software móvil es igual a la de la ingeniería de microcomputadoras
pero en un tamaño reducido, donde se tiene una nueva cultura una nueva forma 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
llegar y así generar los requerimientos necesarios para realizar el proyecto y obtener
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.

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.

Estabilizació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

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

Prueba 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 F04 Nombre Mostrar una bibliotecas

aplicando filtros de búsqueda

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 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.