tesis - .:centro de desarrollo bibliotecario:.biblio.uabcs.mx/tesis/te2949.pdf2.1 ambiente de...
TRANSCRIPT
UNIVERSIDAD AUTÓNOMA DE BAJA CALIFORNIA SUR
ÁREA DE CONOCIMIENTO DE CIENCIAS DEL MAR
DEPARTAMENTO ACADÉMICO DE SISTEMAS COMPUTACIONALES
QUE COMO REQUISITO PARA OBTENER EL TITULO DE:
PRESENTA:
Martha Alicia Gaxiola Fausto
DIRECTOR:
M.S.C. Jaime Suárez Villavicencio
La paz, Baja California Sur, agosto de 2013
TESIS DESARROLLO DE UNA APLICACIÓN MOVIL PARA EL MONITOREO DE
LA PESCA RIBEREÑA EN BAJA CALIFORNIA SUR.
LICENCIADO EN COMPUTACIÓN.
Índice
Capítulo
1.1 Antecedentes……………………………………………………………………...…..…. 1
1.2 Descripción del problema………………...………………………………….………..…3
1.3 Propuesta solución……………………………………………………………....…….....3
1.4 Objetivo general………………………………………………………………….……….3
1.5 Objetivos específicos…………………………………………………...………..……....3
1.6 Cronograma……………………………………………………………………….………4
Capitulo II
2.1 Ambiente de desarrollo para dispositivos móviles…………………………………….5
2.2 Aplicaciones móviles de geolocalización………………………………………..……..6
2.3 Sistemas operativos para dispositivos móviles……………………………………......7
2.4 Android como plataforma para desarrollo de la aplicación móvil…………………..10
2.5 Arquitectura de Android…………………………………………………………………12
2.6 Entorno de aplicación…………………………………………………………………...14
2.7 Las versiones de Android y niveles de API…………………………………………..15
2.8 Elección de la plataforma de desarrollo…………………………………………........22
Capitulo III
3.1 Metodología de desarrollo de software para la aplicación móvil…………….……..24
3.2 Características y requerimientos específicos del entorno móvil……………………24
3.3 Metodología ágil ideal para el desarrollo móvil……………………………………..26
3.4 Metodología Scrum………………………………………………………………..…..27
3.5 Programación extrema (extreme programming, xp)………………………………...28
Capitulo IV
4.1 Análisis y diseño de la aplicación Móvil…………………………………………..…..33
4.2 Caso de uso de la aplicación móvil…………………………………………….……..34
4.3 Diagrama entidad – relación……………………………………………………………36
Capítulo V
5.1 Diseño de interfaces de la aplicación móvil…………………………………….…….37
Capítulo VI
6.1 Resultados…………………………………………………………………………….…43
6.1.1 Comportamiento histórico de la pesquería de escama en bahía…………..........43
6.1.2 Comportamiento histórico de la captura en bahía por pesquería………………..45
6.1.3 Comportamiento histórico de la captura de camarón en esteros………..………46
Índice de figura
Tabla 1.1Cronograma………………………………………………………………………...4
Figura 2.1 Foursquare.........………………………………………………………….………6
Figura 2.2 Google Latitude…….………………….…………………………………………6
Figura 2.3 Grafica de sistemas SO más vendidos………………………………………12
Figura 2.4 Arquitectura de android………………………………………………………..12
Figura 2.5 Dispositivos Android según plataforma instalada, que han accedido a
Google Play Store durante dos Semanas………………………………………………...23
Figura 4.1 Diagrama casos de uso de la aplicación integral……………………………34
Figura 4.2 Diagrama casos de uso de la aplicación móvil…………………………..….35
Figura 4.3 Diagrama entidad relación de la aplicación móvil……………………..…..36
Figura 5.1 Pantalla de inicio de la aplicación móvil………………………………………37
Figura 5.2 Pantalla de opciones de la aplicación móvil………………………………….38
Figura 5.3 Pantalla de captura de avisos de arribo de la aplicación móvil…………….39
Figura 5.4 Pantalla de la opción embarcaciones de la aplicación móvil…………….…40
Figura 5.5 Pantalla de la opción especies de la aplicación móvil………………...…….41
Figura 5.6 Pantalla de la opción campo pesquero de la aplicación móvil……………..42
Figura 6.1 Grafica del comportamiento histórico de la pesquería de escama en
bahía…………………………………………………………………………………...……...44
Figura 6.2 Grafica del comportamiento histórico de la captura en bahía por
pesquería ...…………………………………………………………………………………..45
Figura 6.3 Grafica del comportamiento histórico de la captura de camarón en
esteros …..……………………………………………………………………………………46
Agradecimientos
Quiero agradecer primeramente a dios por darme vida y por haberme dado la
oportunidad de haber llegado a este momento tan importante de mi formación
profesional.
Agradezco a mi esposo Cristian M. corazón por todo su apoyo y comprensión que me
brindo a lo largo de este camino.
A mis padres Alicia F. y Julián G. por la educación que me dieron y gracias a sus
consejos y buenos ejemplos que me demostraron a no rendirme jamás y seguir
adelante y superarme.
A mis hermano Julián G., Manuel Eduardo G. y Julio Cesar G. por su apoyo.
Agradezco a mi maestro y asesor de tesis MSC. Jaime Suárez Villavicencio por su
valiosa guía y asesoramiento a la realización de la misma.
A mis amigos y compañero Gabriel Heras, Aníbal meza, Bernardo chaparro, Francisco
Salazar, Pedro alba y Flavio nava, por que juntos llegamos hasta el final del túnel y
vimos la luz, apoyándonos unos a los otros.
Gracias a todas las personas que ayudaron directa e indirectamente en la realización
de este proyecto.
Dedicatoria
Dedico este trabajo a dios por haberme permitido llegar hasta aquí, A mi familia que
quiero tanto, a mi Esposo, Padres y Hermanos por todo el apoyo que me brindaron y
en especial a mi hija, que todos los esfuerzos hechos hoy en día son para que en un
futuro poder brindarle una mejor calidad de vida.
Espero de corazón hacerlos sentir orgullosos de mi desarrollo profesional que he
Logrado con mucho esfuerzo.
1
Capítulo I
1.1 Antecedentes.
Baja California Sur cuenta con una superficie territorial de 73 677 km 2, la cual representa 3.8 por
ciento del área del país. Ocupa el noveno lugar en extensión y el primero en litorales, con 2 220 km,
que constituye 22 por ciento del litoral nacional total; de éstos, 1 400 corresponden al océano
Pacífico y 820 al golfo de California [1].
La región cuenta con una diversidad de ecosistemas marinos que lo hacen único en el mundo, ya
que alberga especies tropicales, templadas y de transición templado-tropical. Los recursos
pesqueros de BCS son vastos; en las aguas que la circundan, se han identificado 650 especies que
pueden utilizarse para consumo humano e industrialización. Actualmente, se explotan 122 grupos de
especies comestibles, entre las que destacan la sardina, túnidos y almejas. Si bien éstas no tienen
un valor comercial alto con respecto a otras especies, su volumen de producción y el empleo que
generan las hacen importantes. Por otro lado, se cuenta con recursos de alto valor económico, tales
como abulón, langosta y camarón, que sin duda han sido la base de pesquerías altamente rentables
y ejes del desarrollo del sector social, en particular del que se localiza en la zona del Pacífico norte
de la entidad [2]
Hoy en día la preocupación más importante estriba en la contribución de la pesca al desarrollo
sostenible; esto es, satisfacer las necesidades de la generación actual sin poner en peligro las
necesidades de las generaciones futuras. El desarrollo sostenible exige realizar las siguientes
acciones: controlar las actividades que degradan el medio marino; controlar el acceso a los recursos;
implantar medidas para enfrentar la incertidumbre y variabilidad de los recursos naturales; permitir la
recuperación de las poblaciones agotadas e intervenir para restablecerlas; conservar y utilizar de
manera sostenible las poblaciones ícticas y proteger el medio marino; así como garantizar prácticas
selectivas y ecológicas inocuas [3].
Adoptar medidas basadas en la investigación científica para mantener o restablecer las poblaciones
a los niveles que puedan producir el máximo rendimiento sostenible, de conformidad con los factores
ambientales y económicos. Puesto que el exceso de la capacidad de pesca contribuye a la
2
degradación de los recursos pesqueros, a abatir el potencial de producción y a considerables
pérdidas económicas, es indispensable efectuar un ordenamiento centrado en: la integración del
ordenamiento pesquero en el ordenamiento de las zonas costeras; la participación de los integrantes
del sector en el ordenamiento pesquero; los sistemas efectivos de seguimiento, control y aplicación
de medidas de ordenamiento; el compromiso del sector para usar responsablemente los recursos;
evitar el exceso de capacidad de pesca y asegurar que la explotación de las poblaciones continúe
siendo económicamente viable; preservar la biodiversidad y proteger las especies en peligro; y
abatir al mínimo las capturas incidentales, los desperdicios y los descartes [3].
Al igual que en otras regiones de México, el manejo de la pesca en Baja California Sur, se rige bajo
normas oficiales mexicanas como las relacionadas con la del camarón y tiburón y las observaciones
de la Carta Nacional Pesquera. En la mayoría de los casos, las normas y reglas no consideran
diferencias regionales en la dinámica de las flotas, la distribución de los recursos y los impactos
sobre ellos y el ecosistema, derivados de interacciones por la coexistencia espacial y temporal de las
pesquerías. Para apoyar a los procesos de planificación, ordenamiento y manejo pesquero, se
requiere contar con información confiable y oportuna que sirva como apoyo en el proceso de toma
de decisiones, esto requiere de información que permita conocer la situación actual del recurso en
cuanto a disponibilidad y demanda, así como modelos que permitan evaluar escenarios prospectivos
y simular los efectos que producirían ciertas acciones [4].
Se cuenta con un Data Warehouse con datos de pesca ribereña en Baja California Sur, los cuales
contemplan los registros de captura por especie o por grupo y lugar, estos registros son
proporcionados por las mismas embarcaciones y contempla un histórico de 1998 a 2009. Para
mejorar esta acción, se pretende con el uso de una aplicación móvil instalada en un Smartphone
(Teléfono inteligente) las embarcaciones puedan capturar esta información que será depositada en
él Data Warehouse la cual mantendrá un histórico de la pesca ribereña de manera actualizada. Otro
beneficio es la geolocalización en línea con los datos sobre el tipo de especie y capturas realizadas
en la zona, con la cual podrán construir mapas ubicando especies en una zona determinada del
litoral.
3
1.2 Descripción del problema
No existe un mecanismo eficiente para la alimentación de los datos respecto a la captura que
realizan las embarcaciones pesqueras ubicadas en el litoral de Baja California Sur, esto conlleva a
que no se mantengan datos actualizados con respecto a la cantidad, especie y lugar donde es
capturado. Al no contar con la información actualizada, dificulta la toma de decisiones por parte de
los investigadores y productores de las distintas especies, por lo que no se pueden desarrollar con
exactitud los procesos de planificación, ordenamiento y manejo pesquero.
1.3 Propuesta de solución
Desarrollar una aplicación móvil que permita a las embarcaciones pequeña, mediana o grande
dedicada a la pesca ribereña, realizar la captura correspondiente al tipo de especie, cantidad y la
localización del punto donde se ha realizado la misma.
1.4 Objetivo general.
Beneficiar al sector productivo pesquero de Baja California Sur al proveer de información que
permita mantener actualizado los datos en el sistema Data Warehouse sobre la ubicación y captura
de las especies en el litoral de Baja California Sur.
1.5 Objetivos específicos.
Monitoreo en tiempo real, sobre la localización y el tipo de especie que se está capturando
en las zonas del litoral del estado.
Crecimiento en la productividad de la pesca ribereña
Monitoreo de la ubicación de las distintas embarcaciones.
Evaluar escenarios prospectivos y simular los efectos que producirían ciertas acciones
Detectar irregularidades como la captura de especie en temporadas de veda.
4
1.6 Cronograma.
Actividad
2012-2013
Semestre 2
2012
Semestre 1
2013
1 Análisis y Diseño de la herramienta
2 Codificación
3 Plan de pruebas (funcionalidad)
4 Retroalimentación y mantenimiento
5 Prueba en grupo piloto (usabilidad)
6 Implementación
7 Análisis y evolución de los resultados
Tabla 1.1 Cronograma
5
Capítulo II
2.1 Ambiente de desarrollo para dispositivos móviles
El avance tecnológico de los dispositivos móviles, tales como smartphones y tablets, poseen el
poder de procesamiento y la capacidad de memoria que hasta no hace mucho tiempo eran
características de las laptop y hasta computadoras de escritorio de última generación. Esto significa
que hoy en día, estos dispositivos de bolsillo como los smartphones, permiten ejecutar aplicaciones
y acceder a internet desde cualquier lugar, de la misma forma que años atrás sólo era posible desde
una computadora fija.
Este escenario abrió un nuevo mercado para el software, el cual es de gran interés para las
empresas que desean brindar servicios a sus clientes en cualquier lugar donde se encuentren, o
comercializar aplicaciones para estos dispositivos, dado que sus ventas a nivel mundial ya superan a
las de las computadoras personales.
Los Smartphone o teléfonos inteligentes son dispositivos móviles capaces de proporcionar al usuario
servicios de internet a través de WiFi o 3G, por lo que el usuario puede acceder a una serie de
aplicaciones como son; correo electrónico, navegación web. Además estos dispositivos suelen tener
integrado un dispositivo GPS, que junto a la conexión a internet, proporcionan la posibilidad de saber
en cualquier momento la posición actual del móvil.
Haciendo uso de las redes sociales y gracias a la a la proliferación de los dispositivos móviles
inteligentes, se han desarrollado un buen número de aplicaciones denominadas redes sociales
basadas en geolocalización tales como:
6
2.2 Aplicaciones móviles de geolocalización
2.2.1 Foursquare [5], sin lugar a dudas una de las redes de geolocalización más famosas. Se basa
en la capacidad de mostrar un conjunto de lugares en función a la posición en la cual se encuentra
un usuario, para ello el usuario se identifica en la aplicación con su cuenta.
Una vez identificado, el usuario puede listar un conjunto de puntos cercanos a su ubicación y, en su
caso, mostrar las promociones realizadas por estos lugares.
Foursquare también cuenta con un gestor de amigos que permite añadir otros usuarios a la lista de
contactos mediante peticiones de amistad. Para ello, se deben buscar aquellas personas que tengan
la aplicación instalada y que pueden ser localizadas mediante la libreta de direcciones de teléfonos,
Facebook o Twitter. Una vez que un usuario acepte una petición de amistad, Foursquare permite
visualizar aquellos check-in realizados por él, tal caso se muestra en la figura 1.
2.2.2 Google Latitude [6], es la aplicación proporcionada por Google basada en la geolocalización,
capaz de representar tu posición geográfica actual y la de tus amigos en Google Maps con la
intención de facilitar la localización de personas.
Google Latitud interpreta las coordenadas, las empaqueta y las envía, a través de la conexión a
Internet del teléfono móvil, al servidor encargado de compartirlas con el grupo de amigos
previamente configurado. Otra forma de utilizar Google Latitud es desde tu ordenador, donde
puedes ver con tu cuenta la ubicación de tus amigos.
Figura 2.1 Figura 2.2
7
El uso de teléfonos móviles y PDA es un mercado que va en crecimiento. El uso de las redes
sociales, de geolocalización y el entretenimiento, detono la competitividad y el desarrollo de cada
vez mejores dispositivos y a su vez la demanda de más y mejores aplicaciones.
2.3 Sistemas operativos para dispositivos móviles.
Existen ya en el mercado importantes herramientas de trabajo para el desarrollo de aplicaciones
móviles, según los distintos tipos de sistema operativo.
2.3.1 Sistema Android [7]
Fue desarrollado inicialmente por Android Inc., una firma comprada por Google en 2005. Es el
principal producto de la Open Handset Alliance, un conglomerado de fabricantes y desarrolladores
de hardware, software y operadores de servicio. Las unidades vendidas de teléfonos inteligentes con
Android se ubican en los primero puestos de venta en estados unidos y latinoamerica. Tiene una
gran comunidad de desarrolladores escribiendo aplicaciones para extender la funcionalidad de los
dispositivos. A la fecha, se han sobrepasado las 700.000 aplicaciones (de las cuales, dos tercios son
gratuitas) disponibles para la tienda de aplicaciones oficial de Android: Google Play, sin tener en
cuenta aplicaciones de otras tiendas no oficiales para Android como la tienda de aplicaciones
Samsung Apps de Samsung. Google Play es la tienda de aplicaciones en línea administrada por
Google, aunque existe la posibilidad de obtener software externamente. Los programas están
escritos en el lenguaje de programación Java, no obstante, no es un sistema operativo libre de
malware, aunque la mayoría de ello es descargado de sitios de terceros.
La estructura del sistema operativo Android se compone de aplicaciones que se ejecutan en un
framework Java de aplicaciones orientadas a objetos sobre el núcleo de las bibliotecas de Java en
una máquina virtual Dalvik con compilación en tiempo de ejecución. Las bibliotecas escritas en
lenguaje C incluyen un administrador de interfaz gráfica (surface manager), un framework
OpenCore, una base de datos relacional SQLite, una Interfaz de programación de API gráfica
OpenGL ES 2.0 3D, un motor de renderizado WebKit, un motor gráfico SGL, SSL y una biblioteca
estándar de C Bionic. El sistema operativo está compuesto por 12 millones de líneas de código,
incluyendo 3 millones de líneas de XML, 2,8 millones de líneas de lenguaje C, 2,1 millones de líneas
de Java y 1,75 millones de líneas de C++.
8
2.3.2 Sistema iOS [8]
Es un sistema operativo móvil de la empresa Apple Inc. Originalmente desarrollado para el iPhone
(iPhone OS), siendo después usado en dispositivos como el iPod Touch, iPad y el Apple TV. Apple,
Inc. no permite la instalación de iOS en hardware de terceros. La interfaz de usuario de iOS está
basada en el concepto de manipulación directa, usando gestos multitáctiles. Los elementos de
control consisten de deslizadores, interruptores y botones. La respuesta a las órdenes del usuario es
inmediata y provee de una interfaz fluida. La interacción con el sistema operativo incluye gestos
como deslices, toques, pellizcos, los cuales tienen definiciones diferentes dependiendo del contexto
de la interfaz. Se utilizan acelerometros internos para hacer que algunas aplicaciones respondan a
sacudir el dispositivo (por ejemplo, para el comando deshacer) o rotarlo en tres dimensiones (un
resultado común es cambiar de modo vertical al apaisado u horizontal).
iOS se deriva de Mac OS X, que a su vez está basado en Darwin BSD, y por lo tanto es un sistema
operativo Unix.
iOS cuenta con cuatro capas de abstracción: la capa del núcleo del sistema operativo, la capa de
"Servicios Principales", la capa de "Medios" y la capa de "Cocoa Touch". La versión actual del
sistema operativo (iOS 6.1.3) ocupa más o menos 770 megabytes, variando por modelo
2.3.3 Windows 7 Phone [9]
Es un sistema operativo móvil desarrollado por Microsoft, como sucesor de la plataforma Windows
Mobile. A diferencia de su predecesor, está enfocado en el mercado de consumo generalista en
lugar del mercado empresarial por lo que carece de muchas funcionalidades que proporcionaba la
versión anterior. Microsoft ha decidido no hacer compatible Windows Phone con Windows Mobile por
lo que las aplicaciones existentes no funcionan en Windows Phone haciendo necesario desarrollar
nuevas aplicaciones. Con Windows Phone, Microsoft ofrece una nueva interfaz de usuario que
integra varios servicios en el sistema operativo. Microsoft planeaba un estricto control del hardware
que implementaría el sistema operativo, para evitar la fragmentación con la evolución del sistema,
pero han reducido los requisitos de hardware de tal forma que puede que eso no sea posible.
9
2.3.4 WebOS [10]
Es un sistema relativamente reciente. Está desarrollado por la Palm, Inc que ahora pertenece a HP y
basado en Linux (como Android y MeeGO). Para programar sobre él se requiere básicamente
conocimientos de creación de páginas web: HTML, Javascript, CSS, JSON y como entorno de
programación se dispone de Ares, un IDE integrado en un navegador web, con un editor visual
bastante útil.
2.3.5 MeeGO [11]
Es la unión de los sistemas operativos Maemo de Nokia y Moblin de Intel, con los cuales pretendían
competir con el sistema Android de Google. El proyecto del nuevo sistema, a diferencia de Android,
está auspiciado por la Linux Foundation. Nokia presentó su nuevo móvil N9 el cual utiliza el sistema
MeeGo y fue lanzado a finales de 2011. MeeGo se presentó como un sistema preparado para
funcionar en netbooks, dispositivos portátiles, sistemas en vehículos, televisiones y teléfonos
multimedia. Básicamente se trata de una distribución Linux con soporte para ARM e Intel/Atom que
usa Qt para su interfaz.
2.3.6 Symbian [12]
Desarrolla en C++ y Java, normalmente sobre Eclipse. Aun así, existen otras opciones como Origo
IDE, que permite la creación de aplicaciones de manera rápida y visual con un lenguaje de script
propio o lenguajes más comunes como python o ruby, fue un sistema operativo producto de la
alianza de varias empresas de telefonía móvil, entre las que se encuentran Nokia, Sony Mobile
Communications, Psion, Samsung, Siemens, Arima, Benq, Fujitsu, Lenovo, LG, Motorola, Mitsubishi
Electric, Panasonic, Sharp, etc. Sus orígenes provienen de su antepasado EPOC32, utilizado en
PDA's y Handhelds de PSION.
El objetivo de Symbian fue crear un sistema operativo para terminales móviles que pudiera competir
con el de Palm o el Windows Mobile 6.X de Microsoft y ahora Android de Google Inc. , iOS de Apple
Inc. y BlackBerry OS de Blackberry.
10
2.4 Android como plataforma para desarrollo de la aplicación móvil [8]
Cualquier persona que desee desarrollar aplicaciones para móviles tiene que valorar las ventajas y
desventajas de las aplicaciones web y las nativas antes de iniciar cualquier proyecto. La decisión no
depende únicamente de lo fácil o difícil que sea desarrollar la propia aplicación, sino también de
factores como la ventana de oportunidad, el peso que se quiera dar a la experiencia de usuario, el
rendimiento, la agilidad en el mantenimiento y la capacidad de actualización de la propia aplicación o
de la información contenida en ella.
Existen muchas plataformas para móviles (iOS, Symbian, Windows Phone, BlackBerry, Palm, Java
Mobile Edition, Linux Mobile; sin embargo Android presenta una serie de características que lo
hacen diferente. Es el primero que combina en una misma solución las siguientes cualidades:
Plataforma realmente abierta. Es una plataforma de desarrollo libre basada en Linux y
de código abierto. Una de sus grandes ventajas es que se puede usar y customizar el
sistema sin pagar royalties.
Adaptable a cualquier tipo de hardware. Android no ha sido diseñado exclusivamente
para su uso en teléfonos y tabletas. Hoy en día podemos encontrar relojes, cámaras,
electrodomésticos y gran variedad de sistemas empotrados que se basan en este
sistema operativo. Este hecho tiene sus evidentes ventajas, pero también va a suponer
un esfuerzo adicional al programador. La aplicación ha de funcionar correctamente en
dispositivos con gran variedad de tipos de entrada, pantalla, memoria, etc. Esta
característica contrasta con la estrategia de Apple. En iOS tenemos que desarrollar una
aplicación para iPhone y otra diferente para iPad.
Portabilidad asegurada. Las aplicaciones finales son desarrolladas en Java lo que nos
asegura que podrán ser ejecutadas en cualquier tipo de CPU, tanto presente como
futuro. Esto se consigue gracias al concepto de máquina virtual.
Arquitectura basada en componentes inspirados en Internet. Por ejemplo, el diseño
de la interfaz de usuario se hace en XML, lo que permite que una misma aplicación se
ejecute en un móvil de pantalla reducida o en un TV.
Filosofía de dispositivo siempre conectado a Internet.
11
Gran cantidad de servicios incorporados. por ejemplo, localización basada tanto en
GPS como en redes, bases de datos con SQL, reconocimiento y síntesis de voz,
navegador, multimedia.
Aceptable nivel de seguridad. Los programas se encuentran aislados unos de otros
gracias al concepto de ejecución dentro de una caja que hereda de Linux. Además,
cada aplicación dispone de una serie de permisos que limitan su rango de actuación
(servicios de localización, acceso a Internet, etc.)
Optimizado para baja potencia y poca memoria. Por ejemplo, Android utiliza la
Máquina Virtual Dalvik. Se trata de una implementación de Google de la máquina virtual
de Java optimizada para dispositivos móviles.
Alta calidad de gráficos y sonido. gráficos vectoriales suavizados, animaciones
inspiradas en Flash, gráficos en 3 dimensiones basados en OpenGL. Incorpora codecs
estándar más comunes de audio y vídeo, incluyendo H.264 (AVC), MP3, AAC, etc.
Otra comparativa es, se muestra en la siguiente, gráfica en la cual podemos ver un estudio
realizado por la empresa Gratner Group, donde se muestra la evolución del mercado de los
sistemas operativos para móviles según el número de terminales vendidos. Podemos destacar:
el importante descenso de ventas de la plataforma Symbian de Nokia; el declive continuo de
BlackBerry; como la plataforma de Windows que parece que no despega; como Apple tiene
afianzada una cuota de mercado en torno al 15%. Finalmente destacamos el espectacular
ascenso de la plataforma Android, que le ha permitido alcanzar en dos años una cuota de
mercado superior al 75%.
12
Figura 2.3
Porcentaje de teléfonos inteligentes vendidos según su sistema operativo hasta el tercer cuarto del 2012 en el mundo.
2.5 Arquitectura de Android [7].
El siguiente gráfico muestra la arquitectura de Android. Como se puede ver está formada por cuatro
capas. Una de las características más importantes es que todas las capas están basadas en
software libre.
Figura 2.4
Arquitectura de Android.
13
2.5.1 El núcleo Linux
El núcleo de Android está formado por el sistema operativo Linux versión 2.6. Esta capa proporciona
servicios como la seguridad, el manejo de la memoria, el multiproceso, la pila de protocolos y el
soporte de drivers para dispositivos.
Esta capa del modelo actúa como capa de abstracción entre el hardware y el resto de la pila. Por lo
tanto, es la única que es dependiente del hardware.
2.5.2 Runtimede Android
Está basado en el concepto de máquina virtual utilizado en Java. Dado las limitaciones de los
dispositivos donde ha de correr Android (poca memoria y procesador limitado) no fue posible utilizar
una máquina virtual Java estándar. Google tomó la decisión de crear una nueva, la máquina virtual
Dalvik, que respondiera mejor a estas limitaciones.
Algunas características de la máquina virtual Dalvik que facilitan esta optimización de recursos son:
que ejecuta ficheros Dalvik ejecutables (.dex) –formato optimizado para ahorrar memoria. Además,
está basada en registros. Cada aplicación corre en su propio proceso Linux con su propia instancia
de la máquina virtual Dalvik. Delega al kernel de Linux algunas funciones como threading y el
manejo de la memoria a bajo nivel.
También se incluye en el Runtine de Android el “core libraries” con la mayoría de las librerías
disponibles en el lenguaje Java.
2.5.3 Librerías nativas
Incluye un conjunto de librerías en C/C++ usadas en varios componentes de Android. Están
compiladas en código nativo del procesador. Muchas de las librerías utilizan proyectos de código
abierto. Algunas de estas librerías son:
System C library:una derivación de la librería BSD de C estándar (libc), adaptada para
dispositivos embebidos basados en Linux.
14
Media Framework: librería basada en PacketVideo's OpenCORE; soporta codecs de
reproducción y grabación de multitud de formatos de audio vídeo e imágenes MPEG4,
H.264, MP3, AAC, AMR, JPG y PNG.
Surface Manager: maneja el acceso al subsistema de representación gráfica en 2D y
3D.
WebKit: soporta un moderno navegador web utilizado en el navegador Android y en la
vista webview. Se trata de la misma librería que utiliza Google Chrome y Safari de
Apple.
SGL: motor de gráficos 2D.
Librerías 3D: implementación basada en OpenGL ES 1.0 API. Las librerías utilizan el
acelerador harware 3D si está disponible, o el software altamente optimizado de
proyección 3D.
FreeType: fuentes en bitmap y renderizado vectorial.
SQLite: potente y ligero motor de bases de datos relacionales disponible para todas las
aplicaciones.
SSL: proporciona servicios de encriptación Secure Socket Layer.
2.6 Entorno de aplicación[7]
Proporciona una plataforma de desarrollo libre para aplicaciones con gran riqueza e innovaciones
(sensores, localización, servicios, barra de notificaciones,).
Esta capa ha sido diseñada para simplificar la reutilización de componentes. Las aplicaciones
pueden publicar sus capacidades y otras pueden hacer uso de ellas (sujetas a las restricciones de
seguridad). Este mismo mecanismo permite a los usuarios reemplazar componentes.
Una de las mayores fortalezas del entorno de aplicación de Android es que se aprovecha el lenguaje
de programación Java. El SDK de Android no acaba de ofrecer todo lo disponible para su estándar
del entorno de ejecución Java (JRE), pero es compatible con una fracción muy significativa de la
misma.
15
2.6.1 Los servicios
Views: extenso conjunto de vistas, (parte visual de los componentes).
Resource Manager: proporciona acceso a recursos que no son en código.
Activity Manager: maneja el ciclo de vida de las aplicaciones y proporciona un sistema de
navegación entre ellas.
Notification Manager: permite a las aplicaciones mostrar alertas personalizadas en la barra de
estado.
Content Providers: mecanismo sencillo para acceder a datos de otras aplicaciones (como los
contactos).
2.6.2 Las aplicaciones
Este nivel está formado por el conjunto de aplicaciones instaladas en una máquina Android. Todas
las aplicaciones han de correr en la máquina virtual Dalvik para garantizar la seguridad del sistema.
Normalmente las aplicaciones Android están escritas en Java. Para desarrollar aplicaciones en Java
podemos utilizar el Android SDK. Existe otra opción consistente en desarrollar las aplicaciones
utilizando C/C++. Para esta opción podemos utilizar el Android NDK (Native Development Kit).
2.7 Las versiones de Android y niveles de API [7]
Antes de empezar a proyecto en Android hay que elegir la versión del sistema para la que deseamos
realizar la aplicación. Es muy importante observar que hay clases y métodos que están disponibles a
partir de una versión, si las vamos a usar hemos de conocer la versión mínima necesaria.
Cuando se ha lanzado una nueva plataforma siempre ha sido compatible con las versiones
anteriores. Es decir, solo se añaden nuevas funcionalidades y en el caso de modificar alguna
funcionalidad no se elimina, se etiquetan como obsoletas pero se pueden continuar utilizando.
A continuación se describen las plataformas lanzadas hasta la fecha con una breve descripción de
las novedades introducidas. Las plataformas se identifican de tres formas alternativas: versión, nivel
de API y nombre comercial. El nivel de API corresponde a números enteros comenzando desde 1.
Para los nombres comerciales se han elegido postres en orden alfabético Cupcake (v1.5), Donut
16
(v1.6), Éclair (v2.0), Froyo (v2.2), Gingerbread (v2.3). Las dos primeras versiones, que hubieran
correspondido a las letras A y B, no recibieron nombre.
2.7.1 Android 1.0 Nivel de API 1 (septiembre 2008)
Primera versión de Android. Nunca se utilizó comercialmente, por lo que no tiene mucho sentido
desarrollar para esta plataforma.
2.7.2 Android 1.1 Nivel de API 2 (febrero 2009)
No se añadieron apenas funcionalidades simplemente se fijaron algunos errores de la versión
anterior. Es la opción a escoger si queremos desarrollar una aplicación compatible con todos los
dispositivos Android. No obstante apenas existen usuarios con esta versión.
2.7.3 Cupcake, Android 1.5 Nivel de API 3 (abril 2009)
Es la primera versión con algún usuario (aunque apenas la usa un 0,1% en enero de 2013). Como
novedades, se incorpora la posibilidad de teclado en pantalla con predicción de texto, los terminales
ya no tienen que tener un teclado físico, así como la capacidad de grabación avanzada de audio y
vídeo. También aparecen los widgets de escritorio y live folders. Incorpora soporte para bluetooth
estéreo, por lo que permite conectarse automáticamente a auriculares bluetooth. Las transiciones
entre ventanas se realizan mediante animaciones.
2.7.4 Donut, Android 1.6 Nivel de API 4 (septiembre 2009)
Permite capacidades de búsqueda avanzada en todo el dispositivo. También se incorpora gestures y
multi-touch. Permite la síntesis de texto a voz. También se facilita que una aplicación pueda trabajar
con diferentes densidades de pantalla. Soporte para resolución de pantallas WVGA. Aparece un
nuevo atributo XML, onClick, que puede especificarse en una vista. Play Store antes, Android
Market se mejora permitiendo una búsqueda más sencilla de aplicaciones. Soporte para
CDMA/EVDO, 802.1x y VPNs. Mejoras en la aplicación de la cámara.
17
2.7.5 Éclair, Android 2.0 Nivel de API 5 (octubre 2009)
Esta versión de API apenas cuenta con usuarios, dado que la mayoría de fabricantes pasaron
directamente de la versión 1.6 a la 2.1. Como novedades cabría destacar que incorpora un API para
manejar el bluetooth 2.1. Nueva funcionalidad que permite sincronizar adaptadores para conectarlo a
cualquier dispositivo. Ofrece un servicio centralizado de manejo de cuentas. Mejora la gestión de
contactos y ofrece más ajustes en la cámara. Se ha optimizado la velocidad de hardware. Se
aumenta el número de tamaños de ventana y resoluciones soportadas. Nueva interfaz del navegador
y soporte para HTML5. Mejoras en el calendario y soporte para Microsoft Exchange. La clase
MotionEventahora soporta eventos en pantallas multitáctil.
2.7.6 Android 2.1 Nivel de API 7 (enero 2010)
Se considera una actualización menor, por lo que le siguieron llamando Éclair. Destacamos el
reconocimiento de voz que permite introducir un campo de texto dictando sin necesidad de utilizar el
teclado. También permite desarrollar fondos de pantalla animados. Se puede obtener información
sobre la señal de la red actual que posea el dispositivo. En el paquete WebKit se incluyen nuevos
métodos para manipular bases de datos almacenadas en Web. También se permite obtener
permisos de geolocalización, y modificarlos en WebView. Se incorporan mecanismos para
administrar la configuración de la caché de aplicaciones, almacenamiento web, y modificar la
resolución de la pantalla. También se puede manejar vídeo, historial de navegación, vistas
personalizadas.
2.7.7 Froyo, Android 2.2 Nivel de API 8 (mayo 2010)
Como característica más destacada se puede indicar la mejora de velocidad de ejecución de las
aplicaciones (ejecución del código de la CPU de 2 a 5 veces más rápido que en la versión 2.1 de
acuerdo a varios benchmarks). Esto se consigue con la introducción de un nuevo compilador JIT de
la máquina Dalvik.
Se añaden varias mejoras relacionadas con el navegador Web, como el soporte de Adobe Flash
10.1 y la incorporación del motor Javascript V8 utilizado en Chrome o la incorporación del campo de
“subir fichero” en un formulario.
18
El desarrollo de aplicaciones permite las siguientes novedades: se puede preguntar al usuario si
desea instalar una aplicación en un medio de almacenamiento externo (como una tarjeta SD), como
alternativa a la instalación en la memoria interna del dispositivo. Las aplicaciones se actualizan de
forma automática cuando aparece una nueva versión. Proporciona un servicio para la copia de
seguridad de datos que se puede realizar desde la propia aplicación para garantizar al usuario el
mantenimiento de sus datos. Por último, se facilita que las aplicaciones interaccionen con el
reconocimiento de voz y que terceras partes proporcionen nuevos motores de reconocimiento.
Se mejora la conectividad: ahora podemos utilizar nuestro teléfono para dar acceso a Internet a otros
dispositivos (tethering), tanto por USB como por Wi-Fi. También se añade el soporte a Wi-Fi IEEE
802.11n y notificaciones push.
Se añaden varias mejoras en diferentes componentes: En el API gráfica OpenGL ES se pasa a
soportar la versión 2.0. También se puede realizar fotos o vídeos en cualquier orientación (incluso
vertical) y configurar otros ajustes de la cámara. Para finalizar, permite definir modos de interfaz de
usuario (“automóvil” y “noche”) para que las aplicaciones se configuren según el modo seleccionado
por el usuario.
2.7.8 Gingerbread, Android 2.3 Nivel de API 9 (diciembre 2010)
Debido al éxito de Android en las nuevas tabletas ahora soporta mayores tamaños de pantalla y
resoluciones (WXGA y superiores).
Incorpora un nuevo interfaz de usuario con un diseño actualizado. Dentro de las mejoras de la
interfaz de usuario destacamos la mejora de la funcionalidad de “cortar, copiar y pegar” y un teclado
en pantalla con capacidad multitáctil.
Se incluye soporte nativo para varias cámaras, pensado en la segunda cámara usada en
videoconferencia. La incorporación de esta segunda cámara ha propiciado la inclusión de
reconocimiento facial para identificar el usuario del terminal.
La máquina virtual de Dalvik para Android introduce un nuevo recolector de basura que minimiza las
pausas de la aplicación, ayudando a garantizar una mejor animación y el aumento de la capacidad
de respuesta en juegos y aplicaciones similares. Se trata de corregir así una de las lacras de este
19
sistema operativo móvil, que en versiones previas no ha sido capaz de cerrar bien las aplicaciones
en desuso. Se dispone de mayor apoyo para el desarrollo de código nativo (NDK).También se
mejora la gestión de energía y control de aplicaciones. Y se cambia el sistema de ficheros, que pasa
de YAFFS a ext4.
Entre otras novedades destacamos en soporte nativo para telefonía sobre Internet VoIP/SIP. El
soporte para reproducción de vídeo WebM/VP8 y codificación de audio AAC. El soporte para la
tecnología NFC. Las facilidades en el audio, gráficos y entradas para los desarrolladores de juegos.
El soporte nativo para más sensores (como giroscopios y barómetros). Un gestor de descargas para
las descargas largas.
2.7.9 Honeycomb, Android 3.0 Nivel de API 11 (febrero 2011)
Para mejorar la experiencia de Android en las nuevas tabletas se lanza la versión 3.0 optimizada
para dispositivos con pantallas grandes. La nueva interfaz de usuario ha sido completamente
rediseñada con paradigmas nuevos para la interacción, navegación y personalización. La nueva
interfaz se pone a disposición de todas las aplicaciones, incluso las construidas para versiones
anteriores de la plataforma.
Las principales novedades de este SDK son:
Con el objetivo de adaptar la interfaz de usuario a pantallas más grandes se incorporan las
siguientes características: resolución por defecto WXGA (1280×800), escritorio 3D con widgets
rediseñados, nuevos componentes y vistas, notificaciones mejoradas, arrastrar y soltar, nuevo cortar
y pegar, barra de acciones para que las aplicaciones dispongan de un menú contextual siempre
presente y otras características para aprovechar las pantallas más grandes.
Se mejora la reproducción de animaciones 2D/3D gracias al renderizador OpenGL acelerado por
hardware. El nuevo motor de gráficos Rederscript saca un gran rendimiento de los gráficos en
Android e incorpora su propia API.
Primera versión de la plataforma que soporta procesadores multinúcleo. La máquina virtual Dalvik ha
sido optimizada para permitir multiprocesado, lo que permite una ejecución más rápida de las
aplicaciones, incluso aquellas que son de hilo único.
20
Se incorporan varias mejoras multimedia, como listas de reproducción M3U a través de HTTP Live
Sreaming, soporte a la protección de derechos musicales (DRM) y soporte para la transferencia de
archivos multimedia a través de USB con los protocolos MTP y PTP.
En esta versión se añaden nuevas alternativas de conectividad, como las nuevas APIS de Bluetooth
A2DP y HSP con streaming de audio. También, se permite conectar teclados completos por USB o
Bluetooth.
El uso de los dispositivos en un entorno empresarial es mejorado. Entre las novedades introducidas
destacamos las nuevas políticas administrativas con encriptación del almacenamiento, caducidad de
contraseña y mejoras para administrar los dispositivos de empresa de forma eficaz.
A pesar de la nueva interfaz gráfica optimizada para tabletas, Android 3.0 es compatible con las
aplicaciones creadas para versiones anteriores. La tecla de menú, inexistente en las nuevas
tabletas, es reemplazada por un menú que aparece en la barra de acción.
2.7.10 Android 3.1 Nivel de API 12 (mayo 2011)
Se permitemanejar dispositivos conectados por USB (tanto host como dispositivo). Protocolo de
transferencia de fotos y vídeo (PTP/MTP) y de tiempo real (RTP).
2.7.11 Android 3.2 Nivel de API 13 (julio 2011)
Optimizaciones para distintos tipos de tableta. Zoom compatible para aplicaciones de tamaño fijo.
Sincronización multimedia desde SD.
2.7.12 Ice Cream Sandwich, Android 4.0 Nivel de API 14 (octubre 2011)
La característica más importante es que se unifican las dos versiones anteriores (2.x para teléfonos
y 3.x para tabletas) en una sola compatible con cualquier tipo de dispositivo. Entre las características
más interesantes destacamos:
Se introduce un nuevo interfaz de usuario totalmente renovado. Por ejmplo, se reemplazan los
botones físicos por botones en pantalla (como ocurria en las versiones 3.x).
21
Nuevo API de reconocedor facial, permite entre otras muchas aplicaciones desbloquear el teléfono a
su propietario. También se mejora en el reconocimiento de voz. Por ejemplo se puede empezar a
hablar en cuanto pulsamos el botón.
Aparece un nuevo gestor de tráfico de datos por Internet, donde podremos ver el consumo de forma
gráfica y donde podemos definir los límites a ese consumo para evitar cargos inesperados con la
operadora. Incorpora herramientas para la edición de imágenes en tiempo real, con herramientas
para distorsionar, manipular e interactuar con la imagen al momento de ser capturada. Se mejora el
API para comunicaciones por NFC y la integración con redes sociales.
En diciembre del 2011 aparece una actualización de mantenimiento (versión 4.0.2) que no aumenta
el nivel de API.
2.7.13 Android 4.0.3 Nivel de API 15 (diciembre 2011)
Se introducen ligeras mejoras en algunas APIs incluyendo el de redes sociales, calendario, revisor
ortográfico, texto a voz y bases de datos entre otros. En marzo de 2012 aparece la actualización
4.0.4.
2.7.14 Jelly Bean, Android 4.1 Nivel de API 16 (julio 2012)
En esta versión se hace hincapié en mejorar un punto débil de Android: la fluidez del interfaz de
usuario. Con este propósito se incorporan varias técnicas, como: sincronismo vertical, triple búfer y
aumentar la velocidad del procesador al tocar la pantalla.
Se mejoran las notificaciones con un sistema de información expandible personalizada. Los Widgets
de escritorio pueden ajustar su tamaño y hacerse sitio de forma automática al situarlos en el
escritorio. El dictado por voz puede realizarse sin conexión a Internet (de momento en ingles).
Se introducen varias mejoras en Google Search. Se potencia la búsqueda por voz con resultados en
forma de ficha. La función Google Now permite utilizar información de posición, agenda y hora en las
búsquedas.
22
Se incorporan nuevo soporte para usuarios internacionales: como texto bidireccional y teclados
instalables. Para mejorar la seguridad las aplicaciones son cifradas. También se permite
actualizaciones parciales de aplicaciones.
2.7.15 Android 4.2 Nivel de API 17 (noviembre 2012)
Una de las novededes más importantes es que podemos crear varias cuentas de usuario en el
mismo dispositivo. Aunque, esta característica solo está disponible en tabletas. Cada cuenta tendrá
sus propias aplicaciones y configuración.
Los Widgets de escritorio pueden aparecer en la pantalla de bloqueo.Se incorpora un nuevo teclado
predictivo deslizante al estilo Swype.Posibilidad de conectar dispositivo y TVHD mediante wifi
(Miracast). Mejoras menores en las notificaciones. Nueva aplicación de cámara que incorpora la
funcionalidad Photo Sphere para hacer fotos panorámicas inmersivas (en 360º).
2.8 Elección de la plataforma de desarrollo [7]
A la hora de seleccionar la plataforma de desarrollo hay que consultar si necesitamos alguna
característica especial que solo esté disponible a partir de una versión. Todos los usuarios con
versiones inferiores a la seleccionada no podrán instalar la aplicación. Por lo tanto, es recomendable
seleccionar la menor versión posible que nuestra aplicación pueda soportar. Por ejemplo, si nuestra
aplicación necesita utilizar varios cursores simultáneos en la pantalla táctil (multi-touch), tendremos
que utilizar la versión 1.6 al ser la primera que lo soporta. Pero, la aplicación no podrá ser instalada
en versiones anteriores. Para ayudarnos a tomar la decisión de qué plataforma utilizar, puede ser
interesante consultar los porcentajes de utilización:
23
Figura 2.5
Dispositivos Android según plataforma instalada, que han accedido a Google Play Store durante dos semanas
terminado el 3 de enero de 2013.
Tras estudiar la gráfica podemos destacar el reducido número de usuarios que utilizan las versiones
1.x (0.2%). Por lo tanto, puede ser buena idea utilizar como versión mínima la 2.3 para desarrollar
nuestro proyecto, dado que daríamos cobertura a más del 90% de los terminales. Las versiones 3.x
(1,5%) han tenido muy poca difusión y presentan tendencia a disminuir. Las versiones 4.1 y 4.2, con
un 10%, todavía son minoritarias pero se prevé que este porcentaje vaya aumentando. No obstante,
estas cifras cambian mes a mes.
24
Capítulo III
3.1 Metodología de desarrollo de software para la aplicación móvil.
Las Metodologías Ágiles o “ligeras” constituyen un nuevo enfoque en el desarrollo de software, mejor
aceptado por los desarrolladores de proyectos móviles y proyectos web. En febrero del 2001, tras
una reunión celebrada en Utah5, nace el término "ágil" aplicado al desarrollo software. El objetivo fue
esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente
y responder a los cambios que pueden surgir a lo largo del proyecto. Esto pretende ser una
alternativa a los procesos de desarrollo tradicionales caracterizados por su total rigidez y muy
dirigidos a la documentación que se genera tras cada una de las actividades desarrolladas [13].
El desarrollo ágil de software intenta evitar los largos y complicados caminos de las metodologías
tradicionales, enfocándose en las personas y los resultados. Promueve iteraciones en el desarrollo a
lo largo de todo el ciclo de vida del proyecto, desarrollando software en cortos lapsos de tiempo.
Minimiza los riesgos, cada una de esas unidades de tiempo se llama iteración, la cual debe durar
entre una y cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de
requerimientos, diseño, codificación, revisión y documentación. Cada iteración no debe añadir
demasiada funcionalidad, para justificar el lanzamiento del producto al mercado, sino que la meta
debe ser conseguir una versión funcional sin errores. Al final de cada iteración, el equipo volverá a
evaluar las prioridades del proyecto.
3.2 Características y requerimientos específicos del entorno móvil [13]. El desarrollo de aplicaciones móviles difiere del desarrollo de software tradicional en muchos
aspectos, lo que provoca que las metodologías usadas para estos entornos también difieran de las
del software clásico. Esto es porque el software móvil tiene que satisfacer una serie de
requerimientos y condicionantes especiales que lo hace más complejo:
25
Canal radio: consideraciones tales como la disponibilidad, las desconexiones, la variabilidad del
ancho de banda, la heterogeneidad de redes o los riesgos de seguridad han de tenerse
especialmente en cuenta en este entorno de comunicaciones móviles.
Movilidad: aquí influyen consideraciones como la migración de direcciones, alta latencia debido a
cambio de estación base o la gestión de la información dependiente de localización. Sobre esta
última, de hecho, se pueden implementar un sinfín de aplicaciones, pero la información de contexto
asociada resulta muchas veces incompleta y varía frecuentemente.
Portabilidad: la característica portabilidad de los dispositivos terminales implica una serie de
limitaciones físicas directamente relacionadas con el factor de forma de los mismos, como el tamaño
de las pantallas (algo que ha variado sustancialmente con la popularización de las pantallas
táctiles), o del teclado, limitando también el número de teclas y su disposición.
Fragmentación: de la industria: la existencia de una considerable variedad de estándares,
protocolos y tecnologías de red diferentes añaden complejidad al escenario del desarrollo móvil.
Capacidades: limitadas de los terminales: aquí incluimos factores como la baja potencia de cálculo
o gráfica, los riesgos en la integridad de datos, las interfaces de usuario poco funcionales en muchos
aspectos, la baja capacidad de almacenamiento, la duración de las baterías o la dificultad para el
uso de periféricos en movilidad. Factores todos que, por otro lado, están evolucionando en la
dirección de la convergencia de los portátiles (netbooks) con los dispositivos inteligentes
(smartphones) constituyendo cada vez menos un elemento diferencial.
Diseño: desde el punto de vista del desarrollo, el diseño multitarea y la interrupción de tareas es
clave para el éxito de las aplicaciones de escritorio; pero la oportunidad y frecuencia de éstas es
mucho mayor que en el software tradicional, debido al entorno móvil que manejan, complicándose
todavía más debido a la limitación de estos dispositivos.
26
Usabilidad: las necesidades específicas de amplios y variados grupos de usuarios, combinados con
la diversidad de plataformas tecnológicas y dispositivos, hacen que el diseño para todos se convierta
en un requisito que genera una complejidad creciente difícil de acotar.
Time-to-market: en un sector con un dinamismo propio, dentro de una industria en pleno cambio,
los requisitos que se imponen en términos de tiempo de lanzamiento son muy estrictos y añaden no
poca dificultad en la gestión de los procesos de desarrollo.
3.3 Metodología ágil ideal para el desarrollo móvil
Agilidad. Las metodologías ágiles mejoran la flexibilidad del desarrollo y la productividad,
proveyendo métodos que se adaptan a los cambios y que aprenden de la experiencia.
Características específicas de los entornos móviles deben ser procesos iterativos e incrementales,
desarrollo conducido por tests, procesos adaptativos, hablar con el cliente continuamente,
desarrolladores altamente cualificados, asegurar la calidad, revisiones continuas del proceso,
priorización de los requerimientos y bajo time-to-market [14]
Conciencia de mercado. El mercado actual está orientado hacia los productos software por lo que
un proceso de desarrollo móvil debería enfocarse al desarrollo del producto y no del proyecto.
Consecuentemente, los procesos deben enfocarse al nicho del negocio, usando las prácticas de
NPD (New Product Development [15]) haciendo un análisis del mercado. Toda esta información
mitigará las dudas y los riesgos. Procesos orientados al mercado seguirán una planificación bastante
estricta a lo que se refiere a requerimientos de time-to-market. Antes los procesos estaban
orientados a las actividades técnicas ahora tienen que hacer un balance entre las actividades
orientadas a mercado y las técnicas.
Soporte a toda la línea de producción software. Se refiere al "conjunto de sistemas intensivos de
software compartiendo un conjunto de características comunes que satisfacen las necesidades de
un segmento particular del mercado y que son desarrolladas con una serie de valores centrales en
una forma predeterminada" [16]. Esto hace que el ciclo de vida sea más corto, pudiendo desarrollar
27
una familia de productos software móvil en un solo intento, reduciendo costes. Debe tener especial
importancia la línea de producción para la mejora de la calidad del software.
Desarrollo basado en arquitectura. La eficiencia de la línea de producción de software depende
del desarrollo de una plataforma común, por lo que la necesidad de una arquitectura genérica para
una clase de productos es esencial, pudiendo reconfigurarse de forma específica para cada
componente o producto determinado.
Soporte para reusabilidad. El desarrollo basado en componentes y el basado en capas ahorra
costes de desarrollo, agiliza la entrega del producto y hace el software menos propenso a errores ya
que los componentes no deben ser hechos desde cero cada vez.
Inclusión de sesiones de revisión y de aprendizaje. La metodología debería incorporar sesiones
de revisión en todo el proceso para asegurar el análisis del producto y sesiones de aprendizaje
después de la entrega de cada producto para que la experiencia sea analizada y registrada, y así la
abstracción del conocimiento obtenido realimente a todo el equipo.
Especificación temprana de la arquitectura física. La arquitectura física debe ser elaborada en
las etapas tempranas del desarrollo software gracias a que un alto número de riesgos técnicos son
inherentes a las limitaciones de los dispositivos móviles y las diferencias en la implementación
pueden ser obtenidas de características básicas. El uso de un prototipo mitigaría dichos riesgos
técnicos.[17]
3.4 Metodología Scrum [15]
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse
como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma
similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados
externos o internos), y el Team que incluye a los desarrolladores.
28
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo),
el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de
características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de
requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product
Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante
esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver
completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de
ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint,
nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante
el sprint.
Scrum permite la creación de equipos que se auto organizan impulsando la co-localización de todos
los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas
involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden
cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los
desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada.
Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser
completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de
entregar rápidamente y responder a requisitos emergentes.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde
notas y pizarras, hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy
fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.
3.5 Programación extrema (extreme programming, xp)[16]
XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave del
éxito en el desarrollo de software, promueve el trabajo en equipo, se centra en el aprendizaje de los
desarrolladores, y propicia un buen clima de trabajo. XP se basa en realimentación continua entre el
29
cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente
adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo
técnico.
3.5.1 Roles XP
Programador. El programador escribe las pruebas unitarias y produce el código del sistema.
Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación.
Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada
iteración centrándose en aportar mayor valor al negocio.
Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las
pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de
soporte para pruebas.
Encargado de seguimiento (Tracker). Proporciona realimentación al equipo. Verifica el grado de
acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras
estimaciones. Realiza el seguimiento del progreso de cada iteración.
Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de forma que
se apliquen las prácticas XP y se siga el proceso correctamente.
Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema
necesario para el proyecto, en el que puedan surgir problemas.
Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.
30
3.5.2 Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos :
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de
tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe
presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el
software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el
ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio
posible con cada iteración.
El ciclo de vida ideal de XP consiste de seis fases [Xpagil]: Exploración, Planificación de la Entrega
(Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.
3.5.3 Prácticas XP La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva
exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo
funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de
software y a la aplicación disciplinada de las siguientes prácticas.
Planificación. Hay una comunicación frecuente el cliente y los programadores. El equipo técnico
realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y
los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración.
31
Entregas pequeñas . Producir rápidamente versiones del sistema que sean operativas, aunque no
cuenten con toda la funcionalidad del sistema. Esta versión ya constituye un resultado de valor para
el negocio. Una entrega no debería tardar más 3 meses.
Metáfora. El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por
el cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describe cómo
debería funcionar el sistema (conjunto de nombres que actúen como vocabulario para hablar sobre
el dominio del problema , ayudando a la nomenclatura de clases y métodos del sistema).
Diseño simple . Se debe diseñar la solución más simple que pueda funcionar y ser implementada en
un momento determinado del proyecto.
Pruebas . La producción de código está dirigida por las pruebas unitarias. Éstas son establecidas por
el cliente antes de escribirse el código y son ejecutadas constantemente ante cada modificación del
sistema.
Refactorización (Refactoring). Es una actividad constante de reestructuración del código con el
objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible
para facilitar los posteriores cambios. Se mejora la estructura interna del código sin alterar su
comportamiento externo [15].
Programación en parejas. Toda la producción de código debe realizarse con trabajo en parejas de
programadores. Esto conlleva ventajas implícitas (menor tasa de errores, mejor diseño, mayor
satisfacción de los programadores, .).
Propiedad colectiva del código. Cualquier programador puede cambiar cualquier parte del código en
cualquier momento.
Integración continua. Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el
sistema puede llegar a ser integrado y construido varias veces en un mismo día.
32
40 horas por semana. Se debe trabajar un máximo de 40 horas por semana. No se trabajan horas
extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que
debe corregirse. El trabajo extra desmotiva al equipo.
Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Éste es
uno de los principales factores de éxito del proyecto XP. El cliente conduce constantemente el
trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de
manera inmediata cualquier duda asociada. La comunicación oral es más efectiva que la escrita.
Estándares de programación. XP enfatiza que la comunicación de los programadores es a través del
código, con lo cual es indispensable que se sigan ciertos estándares de programación para
mantener el código legible.
33
Capítulo IV
4.1 Análisis y diseño de la aplicación Móvil
Lenguaje Unificado de Modelado (UML) prescribe un conjunto de notaciones y diagramas estándar
para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos
diagramas y símbolos significan.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de
hardware, y organizaciones del mundo real.
UML ofrece los siguientes diagramas para modelar un sistema tales como:
Diagramas de Casos de Uso
Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
Diagramas de Colaboración para modelar interacciones entre objetos.
Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
La aplicación móvil, formará parte de una aplicación integral la cual se define a través del siguiente
esquema representado en UML como lo muestra la figura 6:
1) Aplicación WEB.- Esta aplicación se encarga del mantenimiento de catálogos necesarios
como embarcaciones, campos pesqueros, localidades, permisionarios, especies, entre otros.
Además a través de la aplicación WEB es posible también hacer la captura de avisos de
arribo.
2) Aplicación Móvil.- A través de esta aplicación es posible hacer la captura de los avisos de
arribo directamente en los sitos de desembarque.
3) DSS.- A través de esta aplicación para la toma de decisiones es posible obtener información
estadística de las capturas de especies.
34
Figura 4.1
Diagrama casos de uso de la aplicación integral
4.2 Caso de uso de la aplicación móvil
4.2.1 Capturar aviso de arribo
Este caso de uso permite la captura de los datos contenido en el aviso de arribo. Esta acción la
puede llevar a cabo el permisionario directamente y/o el encargado de la oficina de pesca. El aviso
de arribo se almacena en el dispositivo, para ser enviado posteriormente.
4.2.2 Enviar aviso de arribo
Este caso de uso permite que los avisos de arribo almacenados en el dispositivo se envíen al
servidor donde se almacena la información. Esta operación solo puede hacerse cuando existe
conexión.
4.2.3 Consultar embarcaciones
Este caso de uso permite que el permisionario consulte la información del permiso de pesca. Si el
usuario es el encargado puede consultar la información de todos los permisionarios.
35
4.2.4 Consultar especies
Este caso de uso permite que se pueda consultar información detallada de las especies que se
encuentran en los litorales de Baja California Sur.
4.2.5 Consultar localidades
Este caso de uso permite consultar información detallada de los campos pesqueros del estado de
Baja California Sur.
Figura 4.2
Diagrama casos de uso de la aplicación Móvil
36
4.3 Diagrama entidad – relación.
En la figura 4.3 se muestra el diagrama entidad – relación que utiliza la aplicación móvil de pesca
ribereña.
Embarcación
PK id_embarcación
RNP
num_embarcación
nombre_unidad_economica
tipo_empresa
actividad_pesquera
Especie
PK id_especie
pesqueria
familia
Localidad
PK id_localidad
nombre_localidadAviso_Arribo
PK,FK4 id_Campo_Pesquero
PK,FK1 id_especie
PK,FK3 id_embarcación
PK fecha_aviso
FK2 id_ubicación
peso
precio
esfuerzo
total_embarcaciones
hora_llegada
hora_arribo
dias_efectivos
periodo_dias
Permiso-Especie
PK id_permiso
fecha_permiso
vigencia_permiso
FK1 id_especie
FK2 id_embarcación
Zona
PK id_zona
descripción
Campo_Pesquero
PK id_Campo_Pesquero
nombre_campo
area_manejo
SIMAVI
FK1 id_zona
Figura 4.3
Diagrama Entidad – Relación de la aplicación móvil
37
Capítulo V
5.1 Diseño de interfaces de la aplicación móvil
En la figura 5.1 se muestra la pantalla de inicio de la aplicación móvil, donde es necesario introducir
el nombre de usuario y su contraseña para ingresar a la aplicación.
Figura 5.1
Pantalla de inicio de la aplicación móvil
38
En la figura 5.2 se muestran las opciones que presenta la aplicación móvil: captura de avisos de
arribo, consulta de embarcaciones, consulta de especies y consultas de ubicaciones.
Figura 5.2
Pantalla de opciones de la aplicación móvil
39
En la figura 5.3 se muestra la pantalla que permite la captura de los avisos de arribo de cada
permisionario que llega al sitio de desembarque.
Figura 5.3
Pantalla de captura de avisos de arribo de la aplicación móvil
40
En la figura 5.4 se muestra la pantalla que permite mostrar información de las embarcaciones.
Figura 5.4
Pantalla de la opción Embarcaciones de la aplicación móvil
41
En la figura 5.5 se muestra la pantalla que permite mostrar información de las especies capturadas.
Figura 5.5
Pantalla de la opción Especies de la aplicación móvil
42
En la figura 5.6 se muestra la pantalla que permite mostrar información de los campos pesqueros.
Figura 5.6
Pantalla de la opción Campo pesquero de la aplicación móvil
43
Capítulo VI
6.1 Resultados
La aplicación móvil desarrollada es una herramienta de gran utilidad, dado que alimenta de manera
automática los datos en el Data Warehouse, permitiendo así mantener los datos actualizados lo cual
es de vital importancia para el procesamiento de la información que conlleva a tomar decisiones que
repercuten en el sector pesquero.
La herramienta desarrollada proporciona acceso a los datos de los avisos de arribos de las
embarcaciones de pesca ribereña en el estado de Baja California Sur. Estos datos se pueden
combinar y dividir en cualquier forma posible de acuerdo a las dimensiones del modelo, y facilitar el
monitoreo de la pesca ribereña.
6.1.1 Comportamiento histórico de la pesquería de escama en bahía.
En la figura 6.1 se puede observar el comportamiento histórico de la pesquería de escama en las
bahías de la costa oeste de Baja California Sur en la zona que comprende desde Bahía Magdalena
hasta Bahía Almejas. Esta gráfica pone en evidencia que las bahías de Magdalena, Puerto Chale y
Las Almejas, son las bahías con mayor volumen de captura de escama.
44
Figura 6.1
Comportamiento histórico de la pesquería de escama en bahía.
45
6.1.2 Comportamiento histórico de la captura en bahía por pesquería
En la figura 6.2 se puede observar el comportamiento histórico de la captura de camarón, escama y
tiburón en bahía. En esta gráfica se pone en evidencia que el volumen de captura de escama ocupa
el primer lugar
Figura 6.2
Comportamiento histórico de la captura en bahía por pesquería.
46
6.1.3 Comportamiento histórico de la captura de camarón en esteros.
En la figura 6.3 se puede observar el comportamiento histórico de la pesca ribereña de camarón en
los esteros de la zona de Bahía Magdalena a Bahía Almejas. En esta gráfica se muestra el
comportamiento del volumen de captura por año, y se puede apreciar que los años 1998, 2001 y
2002 son los que acumularon los volúmenes de mayor captura.
Figura 6.3
Comportamiento histórico de la captura de camarón en esteros.
47
Las gráficas generadas permiten visualizar información realmente importante que sirve como base
para detectar algunas irregularidades como: la captura de especies en temporadas de veda,
embarcaciones que capturan en zonas del mar no permitidas, entre otras.
También de la observación de las gráficas obtenidas se pueden inferir algunas conclusiones, y con
éstas, el tomador de decisiones iniciar un análisis de las causas que llevaron a estos resultados, tal
es el caso de los decrementos en los volúmenes de captura, la variación de volumen de pesca en
diferentes temporadas, comportamientos históricos de cada una de las pesquerías.
La información del Data Warehouse puede ser visualizada de múltiples maneras facilitando al
usuario la identificación y la confirmación de tendencias, patrones e hipótesis de los datos
registrados en los avisos de arribo de embarcaciones pequeñas de las capturas de pesquerías en el
estado de Baja California Sur. El conocimiento derivado, es recurso clave para la toma de decisiones
para apoyar a los procesos de planificación, ordenamiento y manejo pesquero en el estado.
48
Bibliografía
[1]http://lanic.utexas.edu/project/etext/colson/35/4.pdf
[2] Casas Valdez, M.et al.(1996), “Recursos pesqueros y acuícolas de Baja California Sur: estado actual y perspectivas de aprovechamiento y desarrollo”, en M. Casas Valdéz y G. Ponce-Díaz (editores), Estudio del potencial pesquero y acuícola de Baja California Sur, vol. I, La Paz, Secretaría de Medio Ambiente, Recursos Naturales y Pesca, Gobierno del estado de Baja California Sur, Organización de Naciones Unidas para la Agricultura y la Alimentación, Universidad Autónoma de Baja California Sur, Centro de Investigaciones Biológicas del Noroeste, Centro Interdisciplinario de ciencias Marinas, Instituto Nacional de la Pesca y Centro Tecnológico del Mar, pp. 1-4
[3]http://cec.itam.mx/medios_digitales/documentos/Estudios_sectoriales/Resumenes_Ejecutivos/Pes
ca.pdf Consultado en octubre de 2012
[4]M. Ojeda y M. Ramírez “Interacciones de pesquerías ribereñas en Bahia Magdalena- Almejas
Baja California Sur. Región y Sociedad”, 2012, pp. 289-204
[5]https://foursquare.com/ Consultado en octubre de 2012
[6]https://www.google.com/latitude?hl=es Consultado en octubre de 2012
[7]http://www.androidcurso.com/index.php/recursos-didacticos consultado en enero de 2013
[8]http://readwrite.com/2010/06/14/android_steals_market_share_from_iphone
[9]http://www.bgr.in/news/wp7-5-minimum-hardware-requirement-specs-change-hints-at-cheaper-
smartphones/ consultado en noviembre de 2012.
[10]http://www.openwebosproject.org/docs/architecture consultado en noviembre de 2012
[11]http://www.genbeta.com/sistemas-operativos/nokia-e-intel-unen-sus-fuerzas-con-meego
consultado en noviembre de 2012
[12] http://www.gsmspain.com/glosario/?palabra=SYMBIAN consultado en noviembre de 2012
[13]http://www.adamwesterski.com/wpontent/files/docsCursos/Agile_doc_TemasAnv.pdf consultado
en enero de 2013
[14] Poppendieck M., Poppendieck T. .Lean Software Development: An Agile Toolkit for Software Development Managers.. Addison Wesley. 2003.
[15] Schwaber K., Beedle M., Martin R.C. .Agile Software Development with SCRUM.. Prentice Hall. 2001.
49
[16] Beck, K.. .Extreme Programming Explained. Embrace Change., Pearson Education, 1999. Traducido al español como: .Una explicación de la programación extrema. Aceptar el cambio., Addison Wesley, 2000. [17] Ulrich, K. T., S.D. Eppinger. Product Design and Development, 3º edición. McGraw-Hill, 2004. [18] Clements, P., Northrop, L., Software Product Lines, course notes of Product Line Systems Program, Software Engineering Institute, Carnegie Mellon University, 2003.