TODOISM

Tema 1.
Fundamentos, Arquitectura y Desarrollo

de Sistemas Móviles
Ingeniería de Sistemas Móviles
Los contenidos de este tema han sido tomados de las siguientes referencias:
- http://www.uco.es/iscbd/iscbd/
- Entornos para el desarrollo de aplicaciones móviles. Revista vínculos vol. 9 Número 1
- FUOC. Fundació per a la Universitat Oberta de Catalunya
- http://arqmoviles.blogspot.com.es/
- http://fundamentosweb-aro.blogspot.com.es/2013/02/sistemas-operativos-moviles.html
1
Introducción
 Actualmente, estamos inmersos en la que se denomina
revolución tecnológica de las comunicaciones inalámbricas, similar a
la que protagonizaron en su momento la electricidad, la televisión, o el
ordenador, que supusieron nuevos modelos de negocio.
 Internet se ha beneficiado de esta tecnología, lo que se conoce
como Internet móvil, que permite que dispositivos móviles y
personas se conecten a la Red desde cualquier lugar y en
cualquier momento.
Ingeniería de Sistemas Móviles 2

Inalámbrico vs Móvil
 Como similitudes podemos referir que el medio de comunicación
utilizado no está confinado a un medio guiado o cable.
 Mallick [1]: No existe una relación bidireccional entre ellas, ya que no
todas las aplicaciones inalámbricas son móviles y viceversa.
 La diferencia se puede identificar en la cobertura de las aplicaciones,
esto es, la necesidad de establecer una comunicación contínua con la
contraparte ; por ejemplo: en una red de área local inalámbrica existirá
comunicación entre los nodos siempre y cuando se encuentren
dentro de la cobertura. Por otra parte las aplicaciones móviles
requerirán del canal de comunicaciones sólo en los casos donde la
comunicación con los otros nodos sea necesaria, podrá continuar la
operación del dispositivo aún sin la conexión permanente con la
red.
[1] Mallick M., (2003), Mobile and Wireless Design

Essentials, ISBN:0471214191 John Wiley & Sons.

Redes de
Ordenadores
4
Redes de ordenadores
 En una red de ordenadores, podemos distinguir cuatro elementos
importantes que intervienen en su definición:
1. El protocolo de comunicación define el lenguaje y el conjunto de reglas
que facilitan la comunicación entre el emisor y el receptor, con el objetivo
de que se puedan entender e intercambiar información. El más conocido y
más extendido entre los ordenadores es el TCP/IP que utiliza Internet.
2. La topología define cómo los nodos de comunicación están
interconectados entre sí. Las topologías de red más comunes son en bus,
estrella, anillo o punto a punto.
3. La seguridad es el elemento que permite garantizar la confidencialidad, la
autenticación y la integridad de los datos.
4. El medio de transmisión es el elemento que diferencia más claramente
las tecnologías de comunicación con hilos de las inalámbricas. Es el
medio por el que viaja la señal que transfiere los datos.

El medio de Transmisión
 Las comunicaciones con cable (guiadas) utilizan distintos medios de transmisión, entre otros,
el par trenzado (UTP 2 o 3 coaxial, la STP ), el cable fibra óptica o los cables de alta tensión.
 El medio de transmisión de las comunicaciones inalámbricas (no guiadas) es el espectro
electromagnético que coloquialmente denominamos aire.
A) Infrarrojos (IR). Se utilizan en comunicaciones punto a punto de corto alcance, son muy
direccionables y no pueden atravesar obstáculos. Este medio se utiliza habitualmente en el
mando a distancia de la televisión y hasta hace unos años para conectar dispositivos
situados el uno al lado del otro. Es el rango de frecuencia más alto para comunicaciones
inalámbricas.
B) Microondas (MW). Este rango de frecuencias es adecuado para transmisiones de largo
recorrido (comunicaciones por satélite, comunicaciones terrestres punto a punto como
alternativa al cable coaxial o la fibra óptica, y también la mayoría de las tecnologías
inalámbricas como UMTS, Bluetooth o WLAN). Las microondas suelen ser direccionales y
utilizan una parte del espectro con frecuencias más pequeñas que los infrarrojos.
C) Radiofrecuencias (RF). Es el rango que utilizan las transmisiones de radio (FM, AM) y
televisión digital terrestre (TDT). Las radiofrecuencias son omnidireccionales y pueden
atravesar obstáculos sin ningún problema.

Comunicaciones inalámbricas. Clasificación
Según el alcance:
 Redes de área personal inalámbrica (WPAN: wireless personal area networks).
 Redes de área local inalámbrica (WLAN: wireless local area networks).
 Redes de área extendida inalámbrica (WWAN: wireless wide area networks).
Podemos diferenciar dos tipos de WWAN, según quién controle su acceso:
 Comunicación fija (FWWAN: fixed wireless wide area networks).
 Comunicación móvil (MWWAN: mobile wireless wide area networks).

Redes personales inalámbricas(WPAN)
 Los dispositivos que pretenden comunicarse han de estar poco
separados. Generalmente, se acepta como límite el espacio de una
habitación o un despacho.
El nombre Bluetooth proviene del rey vikingo Harald Blatand (siglo X),
que unificó y controló Dinamarca y Noruega.
Bluetooth:
Bluetooth es una especificación regulada por el grupo de trabajo IEEE 802.15.1, que
permite la transmisión de voz y datos entre diferentes dispositivos mediante un enlace de
radiofrecuencia en la banda ISM de 2,4 Ghz.
Bluetooth define un alcance corto (alrededor de 10 m) y, opcionalmente, un alcance medio
(alrededor de 100 m).
En una red Bluetooth, cualquier dispositivo puede actuar como maestro o como esclavo:
• El dispositivo maestro se encarga de definir cómo se establece la comunicación
físicamente (frecuencia de salto, fase, etc.).
• Los dispositivos esclavos coordinan sus transmisiones según las especificaciones
del maestro. Normalmente, el primero que solicita el servicio actúa como maestro,
excepto cuando la red ya ha sido establecida.
Para más información visitar: http://www.bluetooth.com

DECT Los aparatos inalámbricos de telefonía de uso doméstico
son los que utilizan más frecuentemente el DECT y,
además, suelen operar con un rango de 50m.
 La tecnología digital enhanced cordless telecommunicatios (DECT) aparece

como una necesidad de que las comunicaciones analógicas de la telefonía
de principios de la década de los ochenta evolucionaran hacia un contexto
digital.
 La transmisión digital inalámbrica ofrece una serie de ventajas: menos
interferencias, más capacidad de dispositivos en una misma zona, más
seguridad (se puede cifrar la información) y más movilidad (se pueden
establecer mecanismos para saltar de una red a otra, característica
denominada roaming).
 El estándar DECT, que originalmente admitía transferencias de datos de
hasta 552 Kbps, ha evolucionado hasta permitir transferencias de 2 Mbps.
Para más información visitar: http://portal.etsi.org/

IrDa
 La Infrared Data Association (IrDA) es una asociación que integra más

de ciento sesenta compañías. El estándar IrDA utiliza el espectro de
frecuencia de infrarrojo para transmitir información.
 El uso de la tecnología IrDA se ha extendido mucho, sobre todo en los
años noventa y a principios de siglo, a causa de su bajo coste de
implementación y su bajo consumo de batería. Además, es muy
flexible y capaz de adaptarse fácilmente a un gran número de
aplicaciones y dispositivos, como a asistentes digitales personales
(PDA), teléfonos, impresoras u ordenadores portátiles.
 Los dispositivos que utilizan la IrDA se comunican mediante el uso del
diodo LED (light emitting diode). Es necesario que estos dispositivos
estén alineadoslos unos con los otros. La desviación máxima permitida
es de 30°.

NFC
 La tecnología NFC comenzó a desarrollarse en el año 2002 en una acción conjunta
de Philips y Sony, con el fin de conseguir un protocolo compatible con las
tecnologías sin contactos propietarias existentes en el mercado: Mifare de Philips
y FeliCa de Sony.
 NFC fue aprobado como el estándar ISO 18092 en diciembre de 2003 y
posteriormente, en marzo de 2004, Philips, Sony y Nokia formaron el NFC Forum
para avanzar en el desarrollo de las especificaciones NFC y velar por su
interoperabilidad.
 NFC opera en la frecuencia de 13.56 MHz, permite la operación a una distancia
inferior a 10 centímetros con velocidades de transmisión de 106 Kbit/s, 212 Kbit/s y
424 Kbit/s.

NFC. Modos de funcionamiento:

NFC. Modos de funcionamiento:

 Una transacción NFC siempre sigue una misma secuencia de operación que consta
de los siguientes pasos:
1. Descubrimiento de dispositivos NFC.
2. Autenticación.
3. Negociación.
4. Transferencia de información y confirmación.
 A bajo nivel, el protocolo NFC incluye un procedimiento para la autenticación segura
y mecanismos anti-colisión para evitar la escucha del canal de comunicación.
 NFC no está diseñado para una transferencia masiva de datos, se puede usar para
configurar otras conexiones inalámbricas que ofrezcan mayor ancho de banda como
son Bluetooth o Wi-Fi.
 Un emparejamiento normal de dispositivos Bluetooth toma entre cinco y seis
segundos o incluso más si el entorno está congestionado, frente a los 200 ms de
NFC

ARQUITECTURA DISPOSITIVO MÓVIL NFC
1. Una bobina o antena incorporada en el

interior del teléfono.
2. El chip NFC.
3. El denominado elemento seguro que es un
chip con características de seguridad
similares a las encontradas en las tarjetas
inteligentes y que se encarga de procesar
de forma segura las transacciones.

NFC. El elemento Seguro
1. Elemento seguro incorporado en la electrónica del móvil: El elemento seguro
puede ser un microcontrolador incorporado en el dispositivo móvil.
Ventaja: El elemento seguro que puede ser incorporado en la actualidad tiene todas las certificaciones
necesarias hardware y software demandadas por el sector bancario.
Desventaja: Su incapacidad de gestionar las credenciales de pago del usuario cuando éste quiere cambiar de
teléfono móvil. Una posible solución a este problema es la gestión mediante el protocolo OTA (Over-The-
Air) de igual forma en la que se produce la inicialización del elemento seguro.
2. Tarjeta de memoria como elemento seguro: con esta solución, una tarjeta de
memoria (SD, MMC, MS, etc) incorpora un chip seguro con un microcontrolador y
memoria flash. Esta solución permite que terceras partes puedan suministrar tarjetas
precargadas con su aplicación.
3. Tarjeta SIM como elemento seguro: con esta arquitectura, la tarjeta SIM incorpora
la aplicación de pago, así como cualquier otra aplicación NFC. La aplicación puede
almacenarse en el propio SIM o como un componente adicional en el conector del
SIM.

NFC. Configuraciones
 Modo emulación de tarjeta inteligente.
 En este modo, el dispositivo NFC se comporta como un tag NFC o una tarjeta inteligente, apareciendo ante un lector
externo como si se tratase de una tarjeta sin contactos.
 Con esta configuración es posible utilizar las características de seguridad avanzada del elemento seguro
incorporado, como medio de pago y para el almacenamiento y gestión de todo tipo de entradas y recibos.
 Un teléfono móvil con capacidad NFC es mucho más barato y fácil de usar que cualquiera de los medios
tradicionales de pago. Inicialmente, los teléfonos móviles se utilizan con esta configuración para ser usados con
máquinas expendedoras, parkings y otros servicios que requieran de una gestión rápida de los pagos.
 Modo ‘Peer to Peer’ para el intercambio de datos o establecimiento de las

comunicaciones entre dispositivos NFC.
 Cuando la cantidad de datos intercambiada es relativamente pequeña (hasta unos pocos kilobytes) se usa el mismo
protocolo NFC.
 Para la transmisión de mayores cantidades de datos, NFC se usa para establecer los parámetros de una conexión
inalámbrica más avanzada como pueden ser Bluetooth o Wi-Fi.
 Modo lector/grabador con capacidad de lectura y escritura de etiquetas o tags.

 En esta configuración el dispositivo NFC es capaz de leer los cuatro tipos de tags especificados por el NFC Forum.
Así mismo, el nivel de acceso físico RF es compatible con el estándar ISO-14443 y FeliCa.
 Cuando el usuario toca con su dispositivo con tecnología NFC a un tag, se transfiere una pequeña cantidad de
información al dispositivo NFC. Esta información puede ser un texto en claro, una dirección de una página web o un
número de teléfono.

Etiquetas NFC
 NFC Tag Tipo 1: estas etiquetas están basada en las especificaciones ISO-14443A, con
capacidad de lectura y escritura. También es posible configurar el tag para que sea de sólo
lectura. La capacidad de memoria es de 96 bytes extensible a 2 Kbytes. La velocidad de
comunicación es de 106 Kbits/s.
 NFC Tag Tipo 2: basadas en las especificaciones ISO-14443A, con capacidad de lectura y
escritura o sólo lectura. La capacidad de memoria es de 48 bytes, ampliable hasta 2 Kbytes.
La velocidad de lectura es de sólo 106 Kbits/s.
 NFC Tag Tipo 3: basadas en un estándar japonés conocido también como FeliCa. Los tags
vienen preconfigurados de fábrica como de lectura y escritura o sólo de lectura. La capacidad
de memoria es variable siendo su límite teórico de 1 Mbyte. La velocidad de comunicación es
de 212 Kbits/s o 424 Kbits/s.
 NFC Tag Tipo 4: tags completamente compatibles con el estándar ISO-14443A y B. Son
configurados desde fábrica como de lectura y escritura o sólo de lectura. La capacidad de
memoria es variable hasta 32 KBytes con una velocidad de comunicación de 424 Kbits/s.

 EJEMPLOS NFC

Zigbee
 Zigbee es un estándar de comunicaciones inalámbricas, regulado por el

grupo de trabajo IEEE 802.15.4 en el 2004, que permite habilitar redes
inalámbricas con capacidades de control, y monitorizar que sean seguras, de
bajo consumo energético y de bajo coste de procesador, de manera
bidireccional.
 ZigBee es promovida por la ZigBee Alliance, una comunidad internacional de
más de cien compañías, como Motorola, Mitsubishi, Philips, Samsung, Ho-
neywell y Siemens, entre otras. De hecho, ZigBee no es una tecnología, sino
un conjunto estandarizado de soluciones que pueden ser implementadas por
cualquier fabricante.
Más información en: www.zigbee.org/

Redes locales inalámbricas (WLAN)
Una WLAN es una red de cobertura geográfica limitada, velocidad de
transmisión relativamente alta, bajo nivel de errores y administrada de
manera privada, que se comunica básicamente mediante microondas.
 La gran difusión de las WLAN se debe a las importantes ventajas que presentan respecto a
las LAN:
 Movilidad: los usuarios de una WLAN pueden acceder a información en
tiempo real desde cualquier lugar de la organización.
 Instalación simple: no hay que preocuparse por la instalación de cables
dentro del radio de cobertura.
 Flexibilidad: permite acceder a lugares que una LAN cableada no
alcanzaría nunca.
 Bajo coste: aunque el coste inicial de instalación de las WLAN puede ser
superior a las LAN con cable, a largo plazo puede suponer un ahorro,
sobre todo en entornos con cambios frecuentes de ubicación de los
dispositivos.
 Escalabilidad: las WLAN se pueden configurar con diferentes topologías
de una manera sencilla según la necesidad del entorno. Podemos tener las
WLAN ad hoc (donde los dispositivos se van añadiendo a la red) y las
WLAN con puntos de acceso conectados a la red principal.

 Desventajas de la WLAN
 Velocidad: las WLAN deben poder transmitir información a velocidades comparables a las LAN (más
de 500 Mbps).
 Retardos: son importantes en cualquier aplicación, pero especialmente en las transmisiones
inalámbricas.
 Accesos difíciles: dentro de un edificio podemos encontrar factores que amortiguan la señal. Un
dispositivo móvil puede recibir mucha menos potencia que otro.
 Consumo: los dispositivos móviles se suelen alimentar con baterías; por lo tanto, hay que diseñarlos
para que tengan un consumo eficiente (modo reposo, modo bajo consumo, poco gasto en la
transmisión de paquetes, etc.).
 Máximo número de nodos y máxima cobertura: una WLAN puede necesitar soportar centenares
de nodos. El área de cobertura típica de una WLAN es de entre 10 y 100 m2, lo que implica retardos
de propagación inferiores a 1.000 nseg.
 Seguridad: el medio en el que se transmite la información (ondas electromagnéticas) es abierto para
cualquiera que esté en el radio de cobertura. Para garantizar la seguridad, se utilizan algoritmos de
cifrado.
 Interferencias: se pueden producir a causa de dos transferencias simultáneas (colisiones) o de dos
emisores que comparten la misma banda de frecuencia. Las colisiones también se producen cuando
varias estaciones que esperan que el canal esté libre empiezan las transmisiones al mismo tiempo. A
diferencia de las redes locales con hilos, en las WLAN se produce un efecto de nodo oculto que
conlleva un aumento de colisiones.

Tecnologías más utilizadas
 El estándar 802.11 describe la funcionalidad de las capas y subcapas y las
relaciones entre ellas, pero no especifica cómo se tienen que hacer; solo indica
cómo se debe comportar el equipo y deja vía libre al fabricante en la manera de
implementarlo.
 El estándar 802.11 es una familia de especificaciones, en la que destacan:

IEEE 802.11a: soporta velocidades de hasta 54 Mbps y utiliza la banda de
frecuencias de 5 GHz. Este protocolo está orientado a la transmisión de paquetes,
pero no soporta funciones de calidad de servicio.

IEEE 802.11b: (inicialmente denominado Wi-Fi): soporta velocidades de hasta 11
Mbps y utiliza la banda de frecuencias de 2,4 Ghz.

IEEE802.11g: soporta velocidades de hasta 54 Mbps. Es una evolución del
• IEEE 802.11i: se creó para superar la vulnerabilidad de seguridad para protocolos
de autenticación y de codificación. El estándar incluye los protocolos 802.1x, TKIP y
AES y se implementa con WPA2.
• IEEE 802.11n: soporta velocidades de hasta 600 Mbps y puede trabajar en dos
bandas de frecuencia: 2,4 GHz (la que utilizan 802.11b y 802.11g) y 5 GHz (la que
utiliza 802.11a). 802.11n es compatible con dispositivos basados en todas las
especificaciones anteriores de 802.11. El hecho de que trabaje en la banda de 5
GHz le permite alcanzar un mayor rendimiento, ya que está menos congestionada.

HiperRLAN
 El high performance radio local area network (HiperLAN) es un

estándar de redes locales inalámbricas desarrollado por el ETSI.
 La primera versión del estándar, HiperLAN1 (HiperLAN Type 1), surgió

en el año 1996 y admitía velocidades de hasta 20 Mbps. La evolución
de este estándar, que apareció en el año 2000, se denomina
HiperLAN2 (HiperLAN Type 2) y admite velocidades de hasta 54
Mbps. Los dos estándares operan en la banda de frecuencias de 5
GHz.
Redes de gran alcance inalámbricas (WWAN)
 Las WWAN permiten la conexión de redes y usuarios de zonas

geográficamente distantes. Podemos distinguir dos tipos:
 WWAN fijas, que utilizan radioenlace o satélite.
 WWAN móviles, que utilizan las compañías u otros servicios
públicos en la transmisión y recepción de señales.
Las redes WWAN móviles (MWWAN) son las que han vivido una
expansión más espectacular en los últimos años. Actualmente las
MWWAN son el sistema de comunicación inalámbrico más utilizado, ya
que es el que utilizan las operadoras de telefonía móvil y cuenta con más
de 5.000 millones de usuarios en todo el mundo.

WWAN fijas (FWWAN)
 Pueden utilizar dos tecnologías:

 Radioenlace. Utilizando radioenlaces se pueden conectar redes
separadas geográficamente con diferentes bandas del espectro
electromagnético (infrarrojos, microondas, láser, etc.), que pueden ser
de punto a punto o de punto a multipunto.
 Satélite. Las comunicaciones por satélite cubren una gran superficie
de la Tierra, tienen un gran ancho de banda y el coste de la
transmisión es independiente de la distancia; presentan el
inconveniente de los retardos de propagación de la señal.
Actualmente, la mayor parte de las redes de satélite se utilizan para la difusión de
televisión. El uso de estas redes para la transmisión de datos inalámbricas es muy
limitado, dado que es necesario tener en cuenta los grandes gastos que conllevan en
equipamiento, los problemas del retardo que se produce al propagarse la señal y el
coste elevado por minuto de transmisión.

WWAN móvil (MWWAN)
 En las redes MWWAN el terminal que envía y recibe la información está en
movimiento. En estas redes normalmente hay muchos usuarios conectados
simultáneamente (acceso múltiple) que utilizan los servicios.
 Actualmente en Europa existen diferentes tecnologías de MWWAN,
agrupadas por generaciones.

MWWAN. 2G (segunda generación).
 Tecnología de segunda generación, utilizada para describir las redes
móviles digitales, como las GSM, que sustituyeron a las redes móviles
analógicas de primera generación. Básicamente estaban diseñadas
para comunicaciones de voz, mensajería instantánea (SMS) y,
esporádicamente, para transmisión de datos básicos que requieren
muy poco ancho de banda. La generación abarca el sistema GSM:
GSM. El Group Special Mobile fue el organismo que se encargó de la

configuración técnica de una normativa de transmisión y recepción para la
telefonía móvil. En Europa, las bandas de frecuencias ISM que se utilizan son
900 MHz y 1.800 MHz. Esta tecnología apareció en el año 1990 con una
velocidad de transmisión de 9,6 kbps. GSM opera por comunicación de circuitos;
esto quiere decir que existe una fase de establecimiento de la conexión que
añade tiempo de espera y que la llamada siempre estará abierta, aunque no
haya transferencia de datos, mientras no se cierre la conexión.

MWWAN. 2.5G (segunda generación y media). Considerada una
tecnología intermedia entre 2G y 3G basada en las actualizaciones
tecnológicas de las redes móviles GSM para aumentar la velocidad de
transmisión de datos y su eficacia.
 La generación abarca los sistemas GPRS y EDGE:

 GPRS. Es una técnica de conmutación de paquetes que empezó a utilizarse en el 2001 y que se
integró con la estructura actual de redes GSM. Esta tecnología permite una velocidad de datos de
entre 56 y 115 kbps. Sus ventajas son múltiples y se aplican fundamentalmente a las transmisiones
de datos que requieren tráfico discontinuo, como por ejemplo Internet y mensajería electrónica (SMS
y MMS). Con esta tecnología, desaparece el concepto de tiempo de conexión y dejan paso al de
cantidad de información transmitida, y se pasa de conmutación de circuitos a conmutación de
paquetes. Los proveedores de servicio de telefonía móvil podrán facturar por los paquetes realmente
enviados y recibidos. El ancho de banda podrá ser entregado a la carta, en función de las
necesidades de la comunicación.
 EDGE. También conocida como EGPRS (Enhanced GPRS), es una tecnología que apareció en el
2003 y considerada una evolución del GPRS. EDGE proporciona un ancho de banda superior a la de
GPRS, entre 236 y 384 kbps, que permite ejecutar aplicaciones que requieren una mayor velocidad
de transferencia de datos, como vídeo y otros servicios multimedia.

MWWAN. 3G (tercera generación). Las tecnologías de 3G son la
respuesta a la especificación IMT-2000 de la Unión Internacional de
Telecomunicaciones (ITU) para disponer de banda ancha en telefonía
móvil y transmitir un volumen de datos importante mediante la red.
Con la tercera generación son posibles las videoconferencias,
descargar vídeos, ver televisión en tiempo real y poder realizar la
mayoría de las operaciones desde el móvil. La generación abarca el
sistema UMTS:
 UMTS. El estándar UMTS está basado en la tecnología WCDMA.
UMTS está gestionado por la organización 3GPP versión 4,
también responsable de GSM, GPRS y EDGE. UMTS se
comercializó por primera vez en el 2005 y su velocidad máxima de
transmisión de datos es 1,92 Mbps.

MWWAN. 3.5G (tercera generación y media). Es la evolución de 3G y
se considera el paso previo de la cuarta generación 4G. La generación
abarca los sistemas HSPA y HSDPA:
 HSPA. Es la combinación de tecnologías posteriores y complementarias a

3G, como HSDPA o HSUPA. Teóricamente, admite velocidades de
hasta14,4 Mbps en bajada y hasta 2 Mbps en subida, dependiendo del
estado o la saturación la red y de su implantación.
 HSDPA. Es la optimización de la tecnología espectral UMTS/WCDMA,

incluida en las especificaciones de 3GPP versión 5 y consiste en un
nuevo canal compartido en el enlace descendente (downlink) que mejora
significativamente la capacidad máxima de transferencia de información
hasta llegar a tasas de 14,4 Mbps, soportando tasas de transmisión
media próximas a 1 Mbps. Es totalmente compatible con UMTS y la
mayoría de los proveedores UMTS dan soporte a esta tecnología.

MWWAN. 4G (cuarta generación). El WWRF define 4G como una integración
de red que funciona con la tecnología de Internet donde toda la red es IP,
combinándola con otros usos y tecnologías, como WiFi y WiMAX. En estos
momentos, 4G no es una tecnología o estándar definido, sino una colección
de tecnologías y protocolos que permiten el máximo rendimiento y con una
red inalámbrica más barata. 4G incluye técnicas inalámbricas de alto
rendimiento, como MIMO y para el acceso radio abandona el acceso tipo
CDMA característico de UMTS (3G) para pasar a OFDMA para optimizar el
acceso. La generación abarca los sistemas LTE y WiMax:
 LTE. Es la clave para el despegue de Internet móvil, ya que posibilita la

transmisión de datos a más de 300 Mbps en movimiento, lo que permite la
transmisión de vídeos o TV de alta definición.
 WIMAX. Es una tecnología, entre WLAN y WWLAN, que permite hacer
conexiones a grandes distancias, con grandes anchos de banda y sin
necesitar línea de visión directa entre antenas. WiMAX cumple los
estándares IEEE 802.16 y es compatible con otros estándares, como el
IEE 802.11, para establecer sistemas de telecomunicaciones conjuntos.

Dispositivos Móviles
33
 Una gran cantidad de dispositivos electrónicos se clasifican
actualmente como dispositivos móviles, desde teléfonos, tablets, hasta
dispositivos como lectores de RFID. Es complicado determinar
cuáles son las características de los dispositivos móviles.
 Características comunes que tienen los dispositivos móviles:
• Son aparatos pequeños.
• La mayoría de estos aparatos se pueden transportar en el bolsillo
del propietario o en un pequeño bolso.
• Tienen capacidad de procesamiento.
• Tienen conexión permanente o intermitente a una red.
• Tienen memoria (RAM, tarjetas MicroSD, flash, etc.).
• Normalmente se asocian al uso individual de una persona, tanto en
posesión como en operación, la cual puede adaptarlos a su gusto.
• Tienen una alta capacidad de interacción mediante la pantalla o el
teclado.

 En general un dispositivo móvil puede definirse con cuatro

características que lo diferencian de otros dispositivos que, aunque
pudieran parecer similares, carecen de algunas de las características
de los verdaderos:
1. Movilidad
2. Tamaño reducido
3. Comunicación inalámbrica
4. Interacción con las personas

Movilidad
 Se entiende por movilidad la cualidad de un dispositivo para ser
transportado o movido con frecuencia y facilidad. Por tanto, el
concepto de movilidad es una característica básica. Los dispositivos
móviles son aquellos que son lo suficientemente pequeños como para
ser transportados y utilizados durante su transporte.
Ejemplo de movilidad:
Un comercial de una empresa farmacéutica carga en su tablet, antes de salir de la
oficina, los datos de los clientes que tiene que visitar. Durante su visita, actualiza o
modifica la información, y una vez terminada su ruta, ya en la oficina o desde el lugar
visitado, actualiza los datos en la aplicación corporativa.

Tamaño Reducido
 Se entiende por tamaño reducido la cualidad de un dispositivo móvil
de ser fácilmente usado con una o dos manos sin necesidad de
ninguna ayuda o soporte externo. El tamaño reducido también permite
transportar el dispositivo cómodamente por parte de una persona.
Los netbooks se consideran a menudo dispositivos móviles debido a su similitud en

cuanto a funcionalidad, pero si el tamaño del dispositivo impide un manejo cómodo (por
ejemplo, sin la ayuda de una mesa) o limita la portabilidad, no se puede considerar un
verdadero dispositivo móvil.

Comunicación Inalámbrica
 Otro concepto importante es el término inalámbrico. Por comunicación
inalámbrica se entiende la capacidad que tiene un dispositivo de
enviar o recibir datos sin la necesidad de un enlace cableado.
Un dispositivo móvil típico es capaz de acceder a Internet, ya sea mediante

redes Bluetooth o WiFi, y muchos modelos están también equipados para
acceder a redes de datos MWWAN, así como a otras redes de datos
inalámbricas.

Interacción con las personas
 Se entiende por interacción el proceso de uso que establece un
usuario con un dispositivo. Entre otros factores, en el diseño de la
interacción intervienen disciplinas como la usabilidad y la ergonomía.
Aparecen conceptos importantes, como la distancia en pantalla, el orden de los
elementos, el tamaño de los textos y las imágenes, la forma de escanear
visualmente las páginas, etc., cambian de unos dispositivos a otros.
Teniendo en cuenta las grandes diferencias físicas (pantalla, teclados, punteros,
etc.), que acarrean formas diferentes de interaccionar, podemos dudar si será
posible, e incluso acertado, alcanzar la famosa web única.

Tipos de dispositivos móviles
 El término dispositivo móvil cubre un amplio rango de dispositivos
electrónicos de consumo. Algunos de estos dispositivos son los
siguientes:
• teléfonos móviles
• organizadores y asistentes personales digitales (personal digital
assistant)
• web-enabled phones
• two-way pagers
• smartphones
• handheld PC
• tablet PC
• tablets
• libros electrónicos (e-books)

Handheld PC
 El concepto de handheld PC es muy antiguo. El diseño puede ser similar al de un

portátil, en el que la pantalla se dobla sobre el teclado y crea una carcasa compacta
alrededor del dispositivo. Por esta razón, los handheld PC fueron comúnmente
conocidos como ordenadores clamshell (cubierta).
 Ideales para la recogida de datos. Incluso teniendo en cuenta que estos beneficios
se podrían conseguir con un portátil, un handheld PC es ideal para el trabajo por las
siguientes razones:
• Los handheld PC proporcionan la función de on y off instantánea, con lo que el
acceso a los datos es inmediato.
• Su batería tiene un largo tiempo de vida debido a los chips de bajo consumo usados
en su diseño. Una única carga de batería puede durar un día entero de uso.
• Al no tener partes móviles, soportan bien los golpes, por lo que se pueden usar en
muchos entornos.
El mercado de los handheld PC está bajo presión, por las cada vez más potentes PDA, y por los cada vez más pequeños
y eficientes portátiles. HP es uno de los fabricantes que más apostó por este mercado. Otros fabricantes se movieron
hacia productos más parecidos a un tablet (como, por ejemplo, el Samsung NEXiO).

Teléfono Móvil
 Los teléfonos móviles simples (al contrario que los smartphones) representaron el
punto de partida para llegar primero a los web-enabled phones y después a los que
hoy se conocen como smartphones. Como dispositivos, se componen de apenas
algunos componentes. Son los siguientes:
• un micrófono
• un altavoz
• una pantalla de cristal líquido o plasma
• un teclado
• una antena
• una batería
• una placa de circuitos
Ventajas: Desventajas:
muy extendido poca potencia de proceso
ligero y transportable. poca memoria
económico capacidades de visualización limitada
prestaciones de comunicación innatas interacción avanzada difícil

Personal digital assistant (PDA)
 Los PDA (a veces llamados ordenadores de bolsillo) combinan

elementos de ordenador, teléfono, fax, Internet y networking en un
único dispositivo. Un PDA puede funcionar como teléfono móvil, fax,
navegador web y organizador personal. Como características
comunes, los PDA ofrecen básicamente calendarios, blocs de notas y
agendas para teléfonos, por lo que han sido los sustitutos tradicionales
de las agendas clásicas.
Desde prácticamente el 2001 se observaba una convergencia entre

dispositivos PDA y dispositivos de voz. A finales del 2001 y durante el
2002, muchos vendedores lanzaron dispositivos combinados de voz y
PDA basados en el Palm OS.

Web-enabled phone
 Los teléfonos móviles son los dispositivos wireless más usados en el

mercado. Por lo general, el uso principal era el de las llamadas de voz,
pero con los mensajes de texto primero y otras tecnologías
inalámbricas para acceder a Internet después, las aplicaciones de
datos se han generalizado.

Smartphone
 Los smartphones combinan los conceptos de teléfono móvil y ordenadores handheld
en un único dispositivo. Los smartphones permiten guardar información (por
ejemplo, correos electrónicos) e instalar programas, además de usar un teléfono
móvil en un único dispositivo. Por ejemplo, un smartphone podría considerarse
como un teléfono móvil con funciones de PDA integradas en el dispositivo o
viceversa.
Entre estas funciones suelen encontrarse la de gestor de correo electrónico, la
funcionalidad completa de organizador personal, y suelen estar pensados para acceder
de manera continua a Internet. Actualmente se les añade como función común la
posibilidad de instalar programas adicionales.

 Tablet: Han dejado de ser un producto del futuro para instalarse como
una realidad presente en el mercado tecnológico.

Componentes de los Dispositivos Móviles
Teclado de un dispositivo móvil: Existen dos grandes familias de
teclados: los físicos y los virtuales.
Teclado QWERTY
 Cuando hablamos de un teclado QWERTY, en realidad estamos
hablando de una distribución de teclas como la que se muestra en la
siguiente figura. El nombre QWERTY viene de la misma disposición
del teclado.

Teclados Fitaly
 Los teclados Fitaly son teclados con una disposición de las teclas
diferente a los teclados QWERTY. Estos teclados se basan en las
probabilidades de teclear una letra. En ellos, las teclas más usadas se
encuentran en el centro.
 Este tipo de teclado existe básicamente en su versión software y está
pensado para la entrada de datos con un único dedo. Era un teclado
utilizado en dispositivos Palm.

Teclado T9
 El teclado T9 usa nueve teclas de tamaño relativamente grande,
distribuidas como las del teclado de marcado de un teléfono. En lugar
de tener que pulsar pequeñas teclas (en comparación con un
QWERTY), se pulsan estos botones de tamaño más grande. Cada
tecla tiene tres letras. La ventaja de este teclado es que no es
necesario pulsar sobre la letra exacta que se desea. Simplemente hay
que pulsar la tecla que tiene la letra deseada. La base de datos del T9
intenta entonces adivinar qué palabra estamos intentando escribir.

Teclado Software Swype
 Swype proporciona una forma rápida y fácil de introducir texto en
cualquier pantalla táctil. Con un movimiento continuo del dedo o del
lápiz a lo largo del teclado en pantalla, esta tecnología permite a los
usuarios introducir palabras de forma más rápida y sencilla que otros
métodos de entrada de datos (unas cuarenta palabras por minuto). La
aplicación está diseñada para trabajar con una gran variedad de
dispositivos (como móviles, tablets, consolas de videojuegos,
televisiones o pantallas virtuales).

Teclado Software Siine
 Si bien con Swype se aprecia una mejora en la forma de introducir los
datos, tras la filosofía de Siine está la premisa de que cambiar la
forma de introducir los datos no es suficiente. Siine aporta la
comunicación textual.
 A diferencia de Swype o Swiftkey, no solo introduce las palabras, sino
que va más allá. Si se utilizan siglas, Siine lo detecta y puede decir lo
que significan. Con Siine no se necesita ningún diccionario, ya que
puede traducir. Siine es un sistema que incorpora inteligencia y
significado.
https://www.youtube.com/watch?v=g884InccVKY

Teclado Software Snapkeys
 Snapkeys es un "teclado" virtual que permite teclear textos sin mirar y
de forma rápida. La peculiaridad de este "teclado" es que,
sencillamente, no tiene teclas.
 El concepto que hay detrás es que el teclado se lo tiene que imaginar
el usuario para así poder escribir rápidamente. Los creadores
aseguran que para los usuarios novatos es preciso en un 92% y para
los experimentados en un 99%, y que se pueden teclear entre sesenta
y ciento sesenta caracteres por minuto.
http://www.youtube.com/watch?v=mLuJhyOKODM

Teclado Software Graffiti
 Graffiti no es un teclado propiamente dicho, sino un sistema de
entrada de texto muy preciso en el que se emplea un lápiz. Con este
lápiz se pueden escribir rápidamente letras y números en el área de
escritura Graffiti. Este es un sistema que incorporan los ordenadores
de mano Palm, junto con una interfaz gráfica muy intuitiva. Este
sistema reconoce una gama completa de letras mayúsculas y
minúsculas, así como dígitos, puntuación y símbolos especiales.

Pantallas de los dispositivos móviles
Pantalla táctil resistiva
 La pantalla se compone, básicamente, de dos capas, entre las cuales
hay una pequeña capa de puntos de plástico. Se proporciona
electricidad a cada una de las capas y, en caso de contacto, se forma
un circuito. La cantidad de electricidad que pasa entre las capas se
mide para determinar el punto de contacto.
Pantalla táctil capacitiva
 La pantalla táctil capacitiva usa una única capa (conocida como grid).
Esta capa está cubierta por un material electroconductor que
proporciona corriente continua con una cierta frecuencia. Cuando se
toca la pantalla con un objeto que emite un flujo de electricidad
constante, como, por ejemplo, un dedo (el cuerpo humano genera
electricidad), se produce un cambio en la corriente y, de esta forma, se
determina el punto de contacto.

Pantallas táctiles infrarrojas ( ópticas y sensibles al calor)
 Las ópticas usan haces infrarrojos, que no son visibles para el ojo humano.
Funcionan con sensores situados encima y alrededor de la pantalla, que forman una
rejilla de haces invisibles. Si un objeto (dedo o stylus) toca la pantalla, interrumpe los
rayos en una cierta área y, de esta forma, se determina el punto de contacto. Tiene
un tiempo de vida de unos siete años y presenta una seria desventaja: un ambiente
con mucha luz puede tener un impacto negativo en su funcionamiento.
 Las sensibles al calor son las más usadas, pero raramente se usan
en pantallas. Se aplican en otros componentes de los dispositivos
móviles, tales como los botones.
Esta tecnología solo funciona con objetos calientes, de modo que tienen
un serio problema: si se tienen los dedos fríos (como puede ocurrir en
invierno) y se tocan estos teléfonos, puede pasar que el dispositivo no
responda.

Pantallas de tinta electrónica
 La tinta electrónica o papel electrónico es una tecnología que permite
crear pantallas planas. Estas pantallas representan información en
blanco y negro y no permiten visualizar imágenes en movimiento. En
el 2007 apareció el primer papel electrónico en color.
 En abril de 1997, los investigadores del Media Lab del MIT crearon la
compañía E Ink para desarrollar una tecnología de tinta electrónica.

Sensores
¿Qué es un sensor?
 Si bien existen variadas definiciones respecto a qué es un sensor,

wikipedia nos entrega una definición bastante buena.
 Un sensor es un dispositivo capaz de detectar magnitudes físicas o

químicas, llamadas variables de instrumentación, y transformarlas en
variables eléctricas. Las variables de instrumentación pueden ser por
ejemplo: temperatura, intensidad lumínica, distancia, aceleración,
inclinación, desplazamiento, presión, fuerza, torsión, humedad,
movimiento, pH, etc. Una magnitud eléctrica puede ser una resistencia
eléctrica, una capacidad eléctrica (como en un sensor de humedad),
una Tensión eléctrica (como en un termopar), una corriente eléctrica
(como en un fototransistor), etc.

Sensores
GPS (Global Positioning System)
 El GPS funciona por medio de una red de satelites que están enviando señales de
forma permanente. Utiliza ondas de radio, pero en lugar de usar torres que están
puestas en el suelo, comunica con satélites que orbitan la tierra.
 Para determinar tu localización, un receptor GPS debe conocer:
• La localización de al menos tres satélites por encima de ti.
• Dónde estas en relación con los satélites.
El receptor utiliza la trilateración para determinar tu

localización exacta. Básicamente, dibuja una esfera
alrededor de cada uno de los tres satélites que puede
localizar. Estas tres esferas se interseccionan en dos
puntos, uno en el espacio y otro en el suelo. El punto en el
suelo donde las tres esferas se interseccionan es donde
estás tú.

Sensores
Usos más comunes de los teléfonos con GPS
 Guía de orientación Los teléfonos móviles GPS, funcionan

prácticamente de la misma forma que un GPS tradicional.
 Localizador Localizador o rastreador lo utilizan por lo general algunos

empresarios para hacerle seguimiento a sus empleados mediante el
celular de la empresa y por otro lado otro uso que va ganando campo
es el seguimiento que hacen los padres de sus hijos.

Sensores
Acelerometro
 El acelerometro es un instrumento utilizado para medir la aceleración y
las fuerzas inducidas por la gravedad, es decir que con un teléfono
móvil podemos detectar su movimiento y su giro
El principio de funcionamiento se basa en un resorte con una

pesada bola de metal, si se mueve la base hacia arriba la bola
se queda atrás estirando el resorte. Si medimos la distancia que
el resorte se estira podemos calcular la fuerza de gravedad. De
esta manera tres de estos dispositivos podrían determinar la
orientaron de un objeto tridimensional.
En la practica dentro del chip hay un pequeño

acelerómetro hecho de silicio. este chip cuenta con
una base que es unida al teléfono y una sección
parecida a un peine que se mueve adelante y atrás.

Sensores
Aplicaciones del acelerómetro
 Por ejemplo en la interfaz de usuario, donde la poner el teléfono en forma horizontal
la imagen cambia adaptándose al formato vertical, de la misma manera al voltear el
teléfono en forma vertical la imagen vuelve a posicionarse en su estado original.
Muchos juegos también utilizan este sensor. Lo

podemos ver por ejemplo en juegos como el Super
monkey ball o el Asphalt5 en donde en ves de
doblar hacia la derecha e izquierda utilizando
botones, se hace mediante el acelerómetro.

Sensores
Sensor de proximidad
 Un sensor de proximidad es un transductor ( osea, convierte un determinado tipo de
energía de entrada, en otra diferente a la salida) que detecta objetos o señales que
se encuentran cerca del sensor. Existen varios tipos:
• sensor capacitivo
• sensor inductivo
• Sensor fin de carrera
• Sensor ultrasonico
• Sensor magnetico
• Sensor infrarojo
Sensor infrarojo
El receptor de rayos infrarrojos es por lo general un fototransistor o un fotodiodo. El circuito

de salida utiliza la señal del receptor para amplificarla y de esta manera adaptarla a una
salida que el sistema sea capaz de entender.

Sensores
Aplicaciones del sensor de Proximidad
 La aplicación mas utiliza de este sensor es cuando hacemos una
llamada. Al hacer una llamada nos acercamos el teléfono al oído, de
esta manera el sensor de proximidad se activa para deshabilitar la
pantalla touch con el fin de que no se presionen botones a lo loco
cuando estemos hablando.
 Otras aplicaciones sirven por ejemplo para bloquear el teléfono

pasando la mano por encima, y también las hay para contestar
llamadas con solo acercar el teléfono al oído.

Sensores
Cámaras en dispositivos móviles
 Elemento indispensable en los teléfonos móviles, la calidad y la
resolución son mejorados de forma constante.
VGA: (Video Graphics Array) CIF: (Common Intermediate Format)
La evolución del formato VGA
QQVGA: 160 x 120 El CIF o Formato Intermedio Comun, era el formato de
QVGA: 320 x 240 video standar que se usaba por lo general en
VGA: 640 x 480 videoconferencias. Este tipo de formatos poseen una
SVGA: 800 x 600 resolución de 352x288 pixeles y una tasa de
XGA: 1024 x 768 transferencia de 30 cuadros por segundo.
SXGA: 1280 x 1024
UXGA: 1600 x 1200
Tipos de Sensores:
CCD: Un sensor CCD esta constituido de fotositos que estan ordenados
en una matriz XY de filas y columnas. Cada fotosito esta constituido de
un fotodiodo y un sector adyacente de carga la cual está protegida de la
luz.
CMOS: La razon por la cual la mayor parte ( por no decir todos) de los
telefonos moviles actuales utilizan sensores CMOS es porque estos
ofrecen un menor consumo de energia, se habla de aproximadamente de
10 veces menos consumo que un sensor CCD.

Sistemas Operativos Móviles
 Los sistemas operativos móviles son un poco más simples que los
sistemas operativos que se utilizan en las computadoras hoy en día
(Windows, Linux, Mac OS, entre otros), pero en esencia son lo mismo.
Un sistema operativo se encarga de controlar el hardware del
dispositivo para así brindar soporte a otras aplicaciones ejecutándose
en el mismo.
 A diferencia de los sistemas operativos para computadoras, los

sistemas operativos móviles están orientados a la conexión
inalámbrica, formatos multimedia comunes en estos dispositivos y
métodos de entrada de datos para el hardware específico (pantallas
táctiles, teclados, botones).

iOS http://www.apple.com/iphone/ios/
http://es.wikipedia.org/wiki/IOS_%28sistema_operativo%29
 Este es un sistema operativos desarrollado por Apple Inc,

originalmente desarrollado para iPhone y luego extendido a sus otros
dispositivos (iPad, iPod, etc). Su interfaz gráfica utiliza pantallas
táctiles y es de muy fácil uso para cualquier usuario.
Características:
• Pantalla Principal con las aplicaciones disponibles
• Multitarea (A partir de la versión 4.0)
• Muchas aplicaciones disponibles a través del App Store
• Compatibilidad con otros dispositivos de Apple
Desventajas:
Ventajas:  Poca interoperabilidad con dispositivos que no son
 Fácil uso Apple
 Seguridad  Precio
 Gráficos  Restricción en el hardware que se puede usar
 Mayor número (solamente el provisto por Apple)
de aplicaciones disponibles  Restricción en cuanto al acceso al App store desde
otros países que no son Estados Unidos
 No soportan contenidos flash o java.
Android http://www.android.com/
http://en.wikipedia.org/wiki/Android_%28operating_system%29
 Es un sistema operativo desarrollado por Google para dispositivos móviles. Es de

código abierto y basado en Linux. Actualmente es el sistema operativo más usado
en Smart Phones. Está principalmente diseñado para dispositivos táctiles, sin
embargo también tiene la capacidad de soportar dispositivos sin esa habilidad.
Características:
• Adapatable a pantallas de mayor resolución
• Soporta múltiples tecnologías (GSM, 3G, 4G, etc)
• Soporte Java y Multimedia
• Multitarea
Ventajas: Desventajas:
 Gran cantidad de aplicaciones disponibles.  Alto consumo de la batería
 Mucha variedad en dispositivos con Android  Sistema operativo menos intuitivo
 Generalmente el hardware tiene mayor  Gráficos de menor calidad
capacidad  Las actualizaciones dependen del fabricante
 Más asequible

Black Berry OS http://es.wikipedia.org/wiki/BlackBerry_OS
http://www.blackberryos.com/
 Black Berry es un sistema operativo propietario desarrollado por Black

Berry Ltda. Está ajustado a los dispositivos BlackBerry que consisten
en un teclado QWERTY, trackball, trackwheel, touchpad y pantallas
móviles. En los últimos meses ha ido decayendo su uso.
Características:
• Está orientado a profesionales, por tanto le facilita al usuario el
acceso a correo electrónico, agenda, contactos, entre otros.
Ventajas:
 Orientado a profesionales y sus necesidades
 Facilidades para que el usuario ingrese datos
Desventajas:
 No hay muchas aplicaciones disponibles
 Pocos desarrolladores tienen acceso de programación.
 La cantidad de usuarios ha venido decayendo.

Otros Sistemas operativos:
 Symbian www.symbian.org
Es un sistema operativo producto de la unión de varias empresas de
telefonía. En estos momentos ya no se utiliza en terminales nuevos y
su uso ha venido decreciendo.
 Meego https://meego.com/
Meego es un sistema operativo móvil basado en linux. En estos
momentos el proyecto se encuentra cerrado en espera de un nuevo
proyecto llamado tizen.
 Tizen https://www.tizen.org/
Tizen es un sistema operativo móvil basado en linux, con el fin de
substituir a Meego. Las interfaces están basadas en html5. Aún no ha
salido al mercado ningún dispositivo que utilice tizen, pero se dice que
este año se van a lanzar smartphones con este sistema operativo.

FIN
70
Tema 2. Diseño y desarrollo de
aplicaciones móviles. Diseño y desarrollo
de sistemas móviles en el ciclo de vida
1
Estamos perdiendo la carrera de relevos
“En enfoque de ‘carrera de relevos’ en el

desarrollo de productos ... puede entrar en
conflicto con los objetivos de máxima
velocidad y flexibilidad. En su lugar, un
enfoque holístico o estilo ‘rugby’ - donde un
equipo intenta ir a la distancia como una
unidad, pasando la pelota hacia adelante y
hacia atrás -pueden servir mejor a los
actuales requisitos competitivos".
Hirotaka Takeuchi and Ikujiro Nonaka,
“The New New Product Development
Game”, Harvard Business Review,
January 1986.

Scrum en 100 palabras
•Scrum es un proceso ágil que nos permite centrarnos
en ofrecer el más alto valor de negocio en el menor
tiempo.
•Nos permite rápidamente y en repetidas ocasiones
inspeccionar software real de trabajo (cada dos
semanas o un mes).
•El negocio fija las prioridades. Los equipos se auto-
organizan a fin de determinar la mejor manera de
entregar las funcionalidades de más alta prioridad.
•Cada dos semanas o un mes, cualquiera puede ver el
software real funcionando y decidir si liberarlo o seguir
mejorandolo en otro sprint.

Orígenes de Scrum
• Jeff Sutherland
• Scrums iniciales en Easel Corp en 1993
• IDX 500 personas haciendo Scrum
• Ken Schwaber
• ADM
• Se presenta Scrum en OOPSLA 96 con Sutherland
• Autor de tres libros sobre Scrum
• Mike Beedle
• Patrones Scrum en PLOPD4
• Ken Schwaber and Mike Cohn
• Fundaron conjuntamente la Scrum Alliance en 2002,
inicialmente dentro de la Agile Alliance

Scrum ha sido utilizado por:
•Microsoft •Intuit
•Yahoo •Nielsen Media
•Google •First American Real Estate
•Electronic Arts •BMC Software
•High Moon Studios •Ipswitch
•Lockheed Martin •John Deere
•Philips •Lexis Nexis
•Siemens •Sabre
•Nokia •Salesforce.com
•Capital One •Time Warner
•BBC •Turner Broadcasting
•Intuit •Oce
Scrum ha sido utilizado para:
• Software comercial •Desarrollo de video juegos
• Desarrollos internos •Sistemas críticos de soporte
vital, aprobados por laFDA
• Desarrollos bajo Contrato
• Proyectos Fixed-price
•Software de control satelital
• Aplicaciones Financieras
•Sitios Web
• Aplicaciones certificadas
•Software para Handheld
ISO 9001 •Teléfonos portátiles
• Sistemas Embebidos •Aplicaciones de Network
switching
• Sistemas con requisitos
7x24 y 99.999% de •Aplicaciones de ISV
disponibilidad
•Algunas de las más grandes
• Joint Strike Fighter aplicaciones en uso

Características
• Equipos auto-organizados
• El producto avanza en una serie de “Sprints"
de dos semanas a un mes de duración
• Los requisitos son capturados como
elementos de una lista de “Product Backlog"
• No hay prácticas de ingeniería prescritas
• Utiliza normas generativas para crear un
entorno ágil para la entrega de proyectos
• Uno de los “procesos ágiles”
El Manifesto Ágil – una declaración de valores
Individuos
Individuos ee sobre
Procesos
Procesos yy
interacciones
interacciones herramientas
herramientas
Software
Software que
que sobre
Documentación
Documentación
funciona
funciona exhaustiva
exhaustiva
Colaboración
Colaboración sobre
Negociación
Negociación de
de
con
con el
el cliente
cliente contratos
contratos
Responder
Responder sobre
Seguimiento
Seguimiento
ante
ante el
el cambio
cambio de
de un
un plan
plan
Fuente: www.agilemanifesto.org
Nivel de ruido de un proyecto
Lejos de
Acuerdo
Anarquía
Complejo
Requisitos
Co
m
pl
ic a Fuente: Strategic Management and
do Organizational Dynamics by Ralph
Stacey in Agile Software Development
with Scrum by Ken Schwaber and Mike
Cerca de Simple Beedle.
Acuerdo
Tecnología
Cerca de
Certeza
Lejos de
Certeza
Scrum
24 horas
Sprint
2-4 semanas
Objetivo del Sprint
Sprint
Incremento del producto
Return Backlog
potencialmente entregable
Gift wrap
Cancel
Product
Backlog

Poniendo todo junto
Imagen disponible en
www.mountaingoatsoftware.com/scrum
Sprints
• En Scrum los proyectos avanzan en una serie

de “Sprints”
• Análogo a las iteraciones en XP
• La duración típica es 2–4 semanas o a lo sumo
un mes calendario
• La duración constante conduce a un mejor
ritmo
• El product es diseñado, codificado y testeado
durante el Sprint

Desarrollo secuencial vs. superpuesto
Requisitos Diseño Código Test
En lugar de hacer todo

de una cosa a la vez ...
...los equipos Scrum
hacen un poco de todo
todo el tiempo
Source: “The New New Product Development Game” by

Takeuchi and Nonaka. Harvard Business Review, January
1986.
No hay cambios en un sprint
Cambios
• Planee la duración del sprint en torno a cuánto

tiempo usted puede comprometerse a
mantener los cambios fuera del sprint
Scrum Framework
Roles
•Product owner
•ScrumMaster
•Team
Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
Scrum framework
Roles
•Product owner
•ScrumMaster
•Team
Reuniones
•Sprint planning
•Sprint review
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
Product Owner (Dueño de Producto)
• Define las funcionalidades del producto

• Decide sobre las fechas y contenidos de los releases
• Es responsable por la rentabilidad del producto (ROI)
• Prioriza funcionalidades de acuerdo al valor del
mercado/negocio
• Ajusta funcionalidades y prioridades en cada iteración
si es necesario
• Acepta o rechaza los resultados del trabajo del equipo

El ScrumMaster
• Representa a la gestión del proyecto

• Responsable de promover los valores y prácticas de
Scrum
• Remueve impedimentos
• Se asegura de que el equipo es completamente
funcional y productivo
• Permite la estrecha cooperación en todos los roles y
funciones
• Escudo del equipo de interferencias externas

El Team
• Típicamente de 5 a 9 personas
• Multi-funcional:
• Programadores, testers, analistas, diseñadores, etc.
• Los miembros deben ser full-time
• Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)
• Los equipos son auto-organizativos
• Idealmente, no existen títulos pero a veces se utilizan de
acuerdo a la organización
• Solo puede haber cambio de miembros entre los sprints

Scrum Framework
Roles
•Product owner
•ScrumMaster
•Team
Reuniones
•Sprint planning
•Sprint review
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
Sprint Planning meeting
Capacidad
Capacidad
del
del Equipo
Equipo
Priorización
• Analizar y evaluar el Product Objetivo
Objetivo
Product
Product Backlog del
del
Backlog
Backlog
• Seleccionar el objetivo del Sprint Sprint
Sprint
Condicione
Condicione
ss del
del Planificación
Negocio
Negocio
• Decidir como alcanzar el
objetivo del Sprint (diseño)
Producto
Producto • Crear el Sprint Backlog (tareas) Sprint
Sprint
Actual
Actual en base a los temas del Product Backlog
Backlog
Backlog (user stories / features)
• Estimar Sprint Backlog en horas
Tecnología
Tecnología

Planificación del Sprint
• El equipo selecciona los temas a partir del Product

Backlog que pueden comprometerse a completar
• Se crea el Sprint Backlog
• Se identifican tareas y cada una es estimada (1-16 horas)
• Realizado colaborativamente, no solo por el ScrumMaster
• El diseño de Alto Nivel es considerado
COMO
COMO planificador
planificador Codificar la capa intermedia (8
de
de vacaciones,
vacaciones, YO
YO hs)
QUIERO
QUIERO ver ver fotos
fotos Codificar la interfaz de usuario (4)
de
de los
los hoteles.
hoteles.
Escribir los test fixtures (4)
Codificar la clase foo (6)
Actualizar test de performance (4)

Daily Scrum
• Parámetros
• Diaria
• Dura 15 minutos
• Parados
• No para la solución de problemas
• Todo el mundo está invitado
• Sólo los miembros del equipo, ScrumMaster y Product
Owner, pueden hablar
• Ayuda a evitar otras reuniones innecesarias

Todos responden 3 preguntas
1
¿Qué hiciste ayer?
2
¿Qué vas a hacer hoy?
3
¿Hay obstáculos en
en tu
tu camino?
camino?
• No es dar un status report al Scrum Master
• Se trata de compromisos delante de pares
Sprint review
• El equipo presenta lo realizado durante el

sprint
• Normalmente adopta la forma de una demo de
las nuevas características o la arquitectura
subyacente
• Informal
• Regla de 2 hs preparación
• No usar diapositivas
• Todo el equipo participa
• Se invita a todo el mundo
Sprint retrospective
• Periódicamente, se echa un vistazo a lo que

funciona y lo que no
• Normalmente 15 a 30 minutos
• Se realiza luego de cada sprint
• Todo el equipo participa
• ScrumMaster
• Product owner
• Equipo
• Posiblemente clientes y otros
Start / Stop / Continue
• Todo el equipo se reúne y discute lo que les gustaría:
Comenzar a hacer
Dejar de hacer
Esto es sólo una
de las muchas
maneras de Continuar haciendo
hacer una
retrospectiva.

Scrum framework
Roles
•Product owner
•ScrumMaster
•Team
Reuniones
•Sprint planning
•Sprint review
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
Product Backlog
•Los requisitos
•Una lista de todos los
trabajos deseados en el
proyecto
•Idealmente cada tema tiene
valor para el usuarios o el
cliente
•Priorizada por el Product
Owner
Este
Este es
es el
el
•Repriorizada al comienzo
de cada Sprint
product
product backlog
backlog
Ejemplo de Product Backlog
Backlog item Estimación
Permitir que un invitado a hacer una reserva. 3
Como invitado, quiero cancelar una reserva. 5
Como invitado, quiero cambiar las fechas de 3

una reserva.
Como un empleado de hotel, puedo ejecutar 8

informes de los ingresos por habitación
disponible Ingeniería de Sistemas Móviles
El objetivo del Sprint
• Una breve declaración de cual será el foco del trabajo durante
el sprint
Ciencias Biológicas
Funciones de apoyo técnico
necesarios para estudios de
Aplicación con B.Datos
genética de poblaciones.
Hacer que la aplicación se
ejecute en SQL Server, además
de Oracle. Servicios Financieros
Soportar más indicadores

técnicos que la empresa ABC en
tiempo real y streaming de datos.

Gestión del Sprint Backlog
• Los individuos eligen las tareas
• El trabajo nunca es asignado
• La estimación del trabajo restante es actualizada
diariamente
• Cualquier miembro del equipo puede añadir, borrar o
cambiar el Sprint Backlog
• El trabajo para el Sprint emerge
• Si el trabajo no está claro, definir un tema del Sprint
Backlog con una mayor cantidad de tiempo y
subdividirla luego.
• Actualizar el trabajo restante a medida de que más se
conoce
Ejemplo de Sprint Backlog
Tareas
Tareas LL M
M M
M JJ V
V
Codificar UI 8 4 8
Codificar negocio 16 12 10 4
Testear negocio 8 16 16 11 8
Escribir ayuda online 12
Escribir la clase foo 8 8 8 8 8
Agregar error logging 8 4

Un Sprint Burndown Chart
Hours

Tareas
Tareas LL M
M M
M JJ V
V
Codificar UI 8 4 8
Codificar Negocio 16 12 10 7
Testear Negocio 8 16 16 11 8
Escribir ayuda online 12
50
40
30
Hours
20
10
0
Mon Tue Wed Thu Fri

Escalabilidad
• Normalmente los equipos son de 7 ± 2 personas

• La escalabilidad proviene de equipos de equipos
• Factores a tener cuenta
• Tipo de aplicación
• Tamaño del equipo
• Dispersión del equipo
• Duración del proyecto
• Scrum se ha utilizado en múltiples proyectos de
más de 500 personas

Expansión a través de Scrum de scrums

Scrum de scrums de scrums

Una lista de lecturas sobre Scrum
• Agile and Iterative Development: A Manager’s Guide by Craig
Larman
• Agile Estimating and Planning by Mike Cohn
• Agile Project Management with Scrum by Ken Schwaber
• Agile Retrospectives by Esther Derby and Diana Larsen
• Agile Software Development Ecosystems by Jim Highsmith
• Agile Software Development with Scrum by Ken Schwaber and
Mike Beedle
• Scrum and The Enterprise by Ken Schwaber
• User Stories Applied for Agile Software Development by Mike
Cohn
• Artículos semanales en www.scrumalliance.org

Comenzando con
Scrum
Este apartado ha sido tomado de : www.asper.es

Elementos de SCRUM

Flujo de Trabajo SCRUM
Daily Scrum Meeting
24 hours
Feedback
P.M. Planning Meeting
A.M. Planning Backlog tasks 30 days

Meeting expanded
by team
Sprint Backlog
Ongoing
adaptation
Potentially Shippable
Product Increment
Product Backlog
As prioritized by Product Owner
Sprint Review Meeting

Feedback

Planificación inicial
 ¿Qué necesitamos para planificar un proyecto de Scrum

inicialmente?
 Dos cosas: una visión y un Producto Backlog
 La visión describe por qué estamos emprendiendo el
proyecto: cuál será la situación final. Si es un proyecto
interno, cómo se mejorará la operativa del
departamento gracias al nuevo producto, y si es
externo cuáles serán sus principales características,
funcionalidades, y cómo afectará al mercado. Es decir,
por qué nos vamos a concentrar las próximas
semanas en esto en lugar de irnos de vacaciones

Product Backlog
 Product Backlog - una lista ordenada de requisitos (“historias” en Scrum),
funcionales y no funcionales, que incorporará nuestro producto final y
permitirán conseguir la visión
 Es el Product Owner el encargado de generar esta lista inicial

y de mantenerla actualizada
 Cualquier persona puede introducir nuevos requisitos en la

lista en cualquier momento, pero…
 … sólo el Product Owner puede priorizarla
 Es decir, cualquier usuario “imaginativo” puede decidir que le gustaría

que el nuevo ERP dejara incorporar fotos personales: introduce el
requisito en el Product Backlog, y probablemente el Product Owner le
otorgue una prioridad 0 y lo envíe al final de la cola
 Los elementos del Product Backlog están priorizados y

estimados

Product Backlog
 Product Backlog - ¿qué campos incluye esta lista? Los mínimos necesarios para
que resulten útiles, como pueden ser:
 ID – un número para identificar la historia
 Nombre – breve descripción de la historia. Muy breve, tipo: “consulta de los
datos del cliente”, o “ver historial de pedidos”
 Categoría – para ayudar en búsquedas, repriorizaciones, etc. Ejemplo:
facturación, reclamaciones, informes, etc
 Solicitante – qué persona incluyó este requisito o lo trasladó al Product
Owner, para poder ofrecerle información de cómo va
 Prioridad – cualquier número que sirva para ordenar su importancia
respecto al resto de historias. Se recomienda la regla “más alto = más
prioritario” (es decir, prioridad 1 sería la menor, y no la mayor)
 Estimación– cuánto trabajo es necesario según el equipo para terminar la
historia. La medida suelen ser “puntos de historia”, que normalmente
equivale a “días ideales” (ver más adelante). No es necesario que la
estimación sea exacta, pero una historia estimada en 10 puntos sí debería
costar la mitad que una estimada en 20 puntos
 Prueba – breve explicación de cómo se demostrará en la demo final que se
ha cumplido con este requisito: “entrar en página de cliente, introducir el DNI
de uno de ellos, y comprobar que se recuperan los datos correctamente.
Modificar uno de los datos, y recuperar de nuevo”

Product Backlog
ID Nombre Categoría Solicitante Prueba Prioridad Estimación
1 Agregar producto Compras Marta Herreros Abrir un pedido 1000 2

al carrito existente, dar a botón
“agregar”,
seleccionar un nuevo
producto, comprobar
que se ha agregado al
carrito
2 Recibir un correo Comunicación con Isabel de la Cruz Cambiar la fecha 950 0,5
cuando el pedido cliente envío del pedido,
se vaya a retrasar comprobar que se
recibe un correo en el
mail asociado al
cliente

Product Backlog
 Cualquier usuario puede agregar historias (es un documento público y
conocido por todos) pero:
 Sólo el Product Owner puede modificar la prioridad. Es él quien decide

cuál es la importancia relativa de cada requisito, qué funcionalidad
necesita antes
 Solo el equipo puede insertar o modificar la estimación
 También miembros del equipo pueden añadir, sobre todo requisitos no

funcionales que consideren importantes (“escribir una descripción general
del diseño”, para que ayude a todos los miembros a no perder el norte).
Estas historias técnicas pueden en ocasiones mantenerse en una lista
aparte.
 Otro tipo de elementos en el Product Backlog:
 Solución de bugs: dentro de cada Sprint se puede incluir una historia
para resolver los bugs de las entregas anteriores, cuando el software ya
está en producción (o bien una historia por cada bug, si tienen la
entidad suficiente)
 Refactorización de código, mejoras técnicas: es posible añadir tareas

que contribuyan a mejorar el código existente, mejorar su legibilidad y
usabilidad, etc

Hasta aquí…
 De momento ya tenemos:
 Un equipo formado, con un Scrum Master y Product Owner

seleccionados, deseando empezar con el proyecto
 Un Product Backlog perfectamente conocido por el Product

Owner; éste debe saber exactamente qué significan cada una
de las historias, tanto si las ha introducido él como cualquier
otra persona
 Estamos listos para empezar a estimar las historias más

prioritarias, y decidir hasta dónde llegaremos en el próximo
Sprint
¡Ahora a estimar!

Y ahora a estimar
 ¿Qué factores influyen a la hora de estimar con exactitud un
requisito? El grado de detalle en la definición del mismo,
tecnología a emplear, conocimientos del desarrollador, su
estado de ánimo e “inspiración” en el momento del desarrollo,
interacciones con otros requisitos… Conseguir dar con una
estimación que resulte exacta parece una tarea imposible
 Por tanto, el objetivo no debe ser dar una estimación
exacta, sino simplemente un grado de aproximación a la
magnitud de los requisitos, en valor absoluto y en relación con
los demás. Al finalizar cada Sprint, comprobaremos si hemos
acertado en las predicciones y el resultado servirá para afinar
más en futuros Sprints, y para actualizar las expectativas de
todos los interesados
 Es decir: no nos obsesionemos con determinar si un requisito
tardará 4 ó 6 días exactamente. Es mejor dar una estimación
de 5 y seguir rápidamente con el siguiente, que invertir 30
minutos en una discusión

¿Estamos estimando todos lo mismo?
 Resulta fundamental aclarar qué incluyen las estimaciones: ¿sólo codificación?
¿tiempo de diseño y codificación? ¿tiempo de pruebas? ¿tiempo de mejora del
código y refactorización?
 Todos los miembros del equipo tienen que acordar el significado de la palabra
“terminado” – es decir, código “terminado” puede querer decir programado,
revisado, realizadas las pruebas unitarias, actualizado el manual de usuario, y
subido al servidor de preproducción. Si alguna de estas etapas falta, el
requisito no está finalizado, aunque el código esté programado
 Es importante para estimar de forma homogénea, y para predecir el tiempo a

invertir posteriormente. Por ejemplo, si no se incluyen tests unitarios, habrá
que aumentar el tiempo estimado de la tarea de corrección de bugs
 En los primeros intentos con Scrum, puede ser aconsejable añadir un campo
en el Product Backlog con la definición de “terminado” para cada historia,
para que no haya problemas. O puede ser simplemente “cuando el encargado
de pruebas del equipo diga que está terminado”
 Recordemos que en Scrum una historia que esté terminada al 90% no está. O
es un entregable completamente funcional, o no contamos con él

Product Backlog
A
B
C Sprint 1
D
No hay cambios DURANTE el Sprint
E
Product Backlog F Una vez cerrados los requisitos de un Sprint, sólo
los miembros del equipo pueden cambiarlos.
G Cualquier modificación o añadido deberá dejarse
para Sprints siguientes
H
…

Jugando a las cartas
 La estimación de cada historia es responsabilidad conjunta de
todo el equipo. ¿Pero cómo evitar que el primero en hablar
condicione el resto de las opiniones?
 Veamos qué sucede cuando se solicita una estimación
tradicional:
- Jefe: “Entonces, ¿cuánto tardaríamos en finalizar esta
historia?”
- Equipo:

- “A” cree que lo sabe, está seguro de que se tardará
3 días, por tanto es el primer en hablar (con
seguridad absoluta)
- Esto despista totalmente a B y C, que habían

pensado en una estimación mucho más alta. D
sigue durmiendo, y E no recuerda de qué se estaba
hablando

- B y C dudan de su estimación inicial, y deciden
acercarse más a lo expresado por A
- D y E no se han molestado en calcularlo, así que el
movimiento más seguro parece ser mostrarse de
acuerdo con A

Jugando a las cartas (Planning Poker)
 De esta manera, terminamos con una estimación totalmente
condicionada por la opinión del primero en hablar
 Scrum funciona de otra manera: todo el mundo debe dar una
estimación (no vale escaquearse), y todo el mundo debe hacerlo a
la vez para no influir a los demás. ¿Cómo lo hacemos?
 Cada miembro del equipo cuenta con un conjunto de cartas con
distintos valores
 Una vez aclarado el significado de cada historia, cada miembro del

equipo selecciona la carta que más se aproxima a su estimación y la
coloca boca abajo. Cuando todos han terminado, se giran las cartas

 No existen cartas para todos los valores posibles. ¿Por qué?
 Para agilizar el proceso, limitando el número de opciones
 Para evitar una falsa sensación de exactitud en las estimaciones
más altas. ¿Realmente alguien es capaz de prever si una tarea
nos llevará 13 o 14 días?
 Para animar al equipo a desmenuzar las historias grandes en
otras más pequeñas. Cualquier historia estimada en 20 o
superior es conveniente dividirla en dos historias más breves
 Algunos valores:
 0 = esta historia ya está hecha, o son sólo unos minutos de
trabajo
 ? = ni idea. Si el uso de esta carta es habitual, es necesario
trabajar más en la comprensión de las historias
 Café = ¡me vendría bien una pausa!

 Dos posibilidades:
 Las estimaciones de todo el equipo son similares:
bingo, es difícil que todos estén muy equivocados. Se
puede escoger la media como estimación final.
 Existen estimaciones muy discrepantes: digamos
que un miembro del equipo dice que 2, y otro opina
que 13. Lo más probable es que hayan entendido
requisitos distintos en la historia, o que uno de ellos se
haya dado cuenta de una complicación que los demás
no han visto. Se discute brevemente hasta aclarar la
situación, y se vota de nuevo, hasta llegar a un
consenso.

Velocidad del equipo
 Supongamos que la estimación de una historia son 5
días. ¿Qué quieren decir esos 5 días?
 Scrum recomienda estimar en “puntos de historia”,
normalmente equivalentes a “dias ideales”:
 Ideal-man-days: si un buen programador se encierra en
una habitación sin interrupciones, con comida y bebida,
concentración total y totalmente enfocado en la
programación, tardaría 5 días en terminar la historia
descrita
 La realidad es que en esos 5 días los teléfonos suenan, el
programador se distrae, surge un bug crítico que debe
resolver inmediatamente, tiene una duda técnica y debe
investigar en Internet…
 Para conjugar ambos mundos existe el concepto de
velocidad del equipo. Veamos qué es.

 Supongamos que nuestro equipo tiene 3 personas y nuestro
Sprint durará 4 semanas:
 David: 20 días disponible
 Ana: 10 días disponible (tiene 2 semanas de vacaciones justo
ahora)
 Jorge: 18 días disponible (se incorpora 2 días tarde)
 En total podemos asumir trabajo correspondiente a 48 días, y
tenemos las siguientes estimaciones realizadas según días
ideales:
8
A
12
B
6
C
Product Backlog ¿eso significa que podemos
D 20
asumir la realizacion de las 5
E 2 primeras historias?
E 3

 No. La historia A se estimó en 8 “días ideales” – no interrupciones,
concentración total –, en condiciones que nunca se darán.
 ¿Entonces cuánto trabajo podemos asumir en nuestros 48 días?
 Si ya has realizado varios Sprints, ya sabes cuál es la media de trabajo que eres
capaz de absorber, cuántos puntos de historia terminas normalmente. Por
ejemplo, una velocidad de 20 significa que normalmente en cada Sprint el
equipo termina historias cuyas estimaciones ideales suman en total 20 puntos –
independientemente de que el Sprint fueran 4 semanas de 3 personas
 En este caso, si ya sabemos que la velocidad del equipo es de 20, sería

razonable asumir que en este Sprint se terminarán las dos primeras historias, la
A y la B
 ¿Y qué ocurre en el primer Sprint? Aún no conocemos la velocidad del equipo.

Simplemente asume un valor razonable (por ejemplo, 50%; si dispones de 48
días/hombre, asume historias por valor de 24), y ya irás ajustando en Sprints
sucesivos. Normalmente tras varios Sprints, ya eres capaz de determinar una
velocidad aproximada que encaje con el equipo.

Y ahora a estimar
 Entonces ya sabemos:
 Quién estima = todos
 Cómo estimamos = con cartas
 Qué significa “terminado” en cada tarea
 Qué significa la “velocidad” del equipo
 Ahora, ¿cómo se realiza esta fase de estimación?

 Es la reunión de planificación del Sprint (sprint
planning meeting). Vamos a ver en qué consiste.

Planning Poker
El moderador coge una historia y la explica al equipo.

 Los integrantes del equipo hacen las preguntas necesarias para aclarar los
aspectos que no entendieron de la historia.
 Cuando todo el equipo parece entender la historia se inicia la primera
ronda, cada integrante estima el esfuerzo y simultáneamente sueltan una
tarjeta sobre la mesa.
 Si existe una diferencia significativa entre la estimación mayor y menos, las
personas que realizaran estas estimaciones iniciarán el debate explicando
por qué han dado esa estimación.
 De nuevo se vuelve a estimar y todo el equipo vuelve a sacar una carta.
Generalmente se suele llegar a un consenso en la segunda ronda, si no es
así, se volverá a intentar (rara vez supera la tercera ronda). El objetivo es
alcanzar un mínimo de consenso, no que todos saquen la misma carta.

Alternativa al Planning Poker. T-Shirt Sizing
 Identificar los elementos más pequeños de tamaño para que actúe
como punto de referencia (S).
 Grupo de cada tarjeta, con cada grupo correspondiente
aproximadamente dos veces tan grande como el primero. .
(M = S + S, L = M + M).
 Cualquier elemento más grande que XL es una epopeya que es
demasiado grande para estimar. Estos deben ser re-evaluado y
analizado en un tamaño que se puede estimar.
 Una vez que todos los artículos (cartas) se colocan en sus grupos. Los
puntos se asignan a cada tamaño.
 Números Fibonacci se puede utilizar o simplemente el doble, por
ejemplo:..
Doble: S = 1, H = 2, L = 4, XL = 8 .
Fibonacci:.. S = 1, M = 3, L = 8, XL = 13.

Swim-Lanes Sizing
Primera iteración
• En silencio!!!!
– Colocar las historias mas cortas en el carril de más a la izquierda
– Las historias poco comprensibles sobre el carril de mas a la derecha
» Se entiende que los miembros del equipo tienen algún conocimiento de todas
las historias ya que el Product Owner ya participo en la planificación
• No puede una historia cubrir mas de un carril

Swim-Lanes Sizing
Segunda iteración
• Con el escenario actual cree que su historia debe cambiar su carril?
En silencio!!!
– Cambiar de ser necesario la historia del carril

Swim-Lanes Sizing
Primera Validación
• Cual es el nivel de confianza sobre la ubicación de las historias en una
escala de 1 a 5?
•Si la confianza de un miembro es < 3
– cada miembro del equipo tiene 2 minutos para decir sus observaciones
sobre las historias y que el equipo decida si se mueve de carril o
permanece en su posición.

Swim-Lanes Sizing
Segunda validación
• Sobre el carril de mas a la izquierda, Crees que se estará trabajando en
cosas mas pequeñas?
– Si la respuesta es «Si» etiquetar los carriles con 3 o 5
– Si la respuesta es «No» etiquetar los carriles con 1 o 2
• Luego asignar al resto de las columnas un valor según la secuencia de
fibonacci modificada
SI NO

Reunión de Planificación del Sprint
 Antes de cada Sprint, el equipo + Scrum Master + Product Owner se
reúnen para decidir qué parte del Product Backlog se aborda en el
periodo siguiente
 Se recomienda que la reunión dure un día:
 4 horas: el Product Owner explica en detalle las primeras historias, y
responde las dudas del equipo hasta que éstos tienen claro exactamente
cuál es el objetivo deseado con ellas. El equipo estima la duración de las
historias. Conociendo cuántos días tiene el Sprint y cuál es la velocidad del
equipo, es por tanto capaz de seleccionar las historias que “caben” en el
Sprint. Éste será el objetivo para el Sprint: ¿qué conseguiremos con este
software productivo? Es importante definir claramente la meta
(“implementar el catálogo de productos”, “desarrollar la home de la Web y el
apartado de consultas”, etc)
 4 horas: el equipo desglosa las historias del Sprint en tareas y estima el
tiempo de cada una de ellas. Por ejemplo, la historia “alta de pedido” puede
desglosarse en “selección de productos del catálogo”, “captura de datos de
facturación”, “cálculo de importe final”,…
 Cada tarea debería durar entre 4 y 16 horas: si dura más, divídela en tareas
más pequeñas hasta que tengas unidades manejables
 Cada tarea tendrá siempre un responsable de su ejecución dentro del equipo
 Asimismo se decide la hora y lugar de celebración de las reuniones diarias,

y se fija la fecha de la demo del Sprint

Time-boxing
 Hagamos un inciso: una práctica fundamental de Scrum es el
time-boxing:
 Las reuniones diarias duran 15 minutos. Y no más.
 La reunión de planificación dura 8 horas. Y no más.
 Etc
 El saber que existe una duración prelimitada ayuda a enfocar

los temas, no irse por las ramas, y tratar de ser lo más
efectivo posible.
 Es importante que el Scrum Master sea estricto con el
cumplimiento de esta norma. Algunas veces puede ser
traumático, pero la gente aprende y la próxima vez se
esfuerza por cumplirlo

Product Sprint
 ¿En qué formato se maneja el Producto Sprint (es
decir, historias y tareas que caben en esta
iteración)?
 Software especializado. Hoy en día existen muchas
aplicaciones diseñadas para gestionar Scrum (como
VersionOne, por ejemplo)
 La clásica Excel con la información imprescindible (y
no más) para saber de qué estamos hablando
 Tarjetas físicas. Tiene algunas ventajas: es más
visual, el equipo las manipula físicamente, se
repriorizan cambiándolas de sitio, y al terminar la
reunión pueden colgarse directamente en la pared
(ver más adelante) en el panel del Sprint. Sería algo
así:

Product Sprint
ID de la historia Nombre de la historia
15 ALTA DE PEDIDO Prioridad

Brevemente, cómo establecida
demostraremos en la Cómo se prueba Prioridad por Product
demo que se cumple Owner
con la historia Elegir cliente, seleccionar dos productos
del catálogo, seleccionar modo de pago.
Comprobar la creación del pedido y 20
asignación número pedido.
Estimación
establecida por
Solicitante Estimación el equipo
Cualquier otra Yolanda Córdoba – Dpto. Ventas
información que resulte
realmente útil: quién Categoría 5
solicita, agrupación en
categorías… Módulo Ventas

Product Sprint
 Cada historia se subdivide en tareas manejables y asignables a una persona en concreto.

La forma más visual de realizarlo es añadiendo post-its o tarjetas menores debajo de cada
tarjeta de historia
15 ALTA DE PEDIDO
 Esta división en tareas puede variar
Cómo se prueba Prioridad
bastante a lo largo de la vida del Sprint,
Elegir cliente, seleccionar dos
así que en ocasiones no se detalla en productos del catálogo, seleccionar
20
ningún Excel ni otro tipo de soporte. Se modo de pago. Comprobar la creación
del pedido y asignación número pedido.
cuelga en el panel de la pared (ver a
continuación), y está disponible allí para Solicitante Estimación
cualquiera que desee consultarlo Yolanda Córdoba – Dpto. Ventas
Categoría 5
 Diferencia entre historia y tarea: las Módulo Ventas
historias tienen sentido de negocio para

el cliente, son entregables para el Mostrar Generación
Product Owner. Las tareas no. productos número
catálogo Pruebs y
pedido
debug errores
Calcular
importe
pedido +
impuestos

Product Sprint
 Tras la reunión de planificación del Sprint debemos haber
conseguido:
 Que todos los miembros del equipo tengan claro el sentido de
cada historia
 El conjunto de historias que abordaremos en este Sprint
 El desglose de estas historias en unidades manejables
(tareas) con una estimación para cada tarea
 El lugar y hora de celebración de la demo del Sprint
 El lugar y hora donde se van a celebrar las reuniones diarias
 Al día siguiente comienza el Sprint. ¿Cómo empezamos?

Recuerda que nadie le dice a nadie lo que tiene que hacer…

Daily Scrums
 El seguimiento del proyecto se lleva a cabo mediante el daily scrum, o
reunión diaria. ¿Qué es?
– Reunión del equipo y el Scrum Master. Además de ellos puede

asistir quien quiera, pero NO puede opinar. Es sólo para el equipo
– Tiempo máximo = 15 minutos. Hay que ser operativos
– Preferiblemente de pie. Evita que la reunión se alargue
– Cada miembro del equipo contesta a tres preguntas:
• Qué hice ayer

• Qué voy a hacer hoy
• Qué impedimentos tengo para poder realizarlo
– Cualquier otra discusión que pueda surgir, se saca del daily scrum
y se comenta en reunión aparte

Daily Scrums
 Por tanto el primer día el equipo tiene una lista de historias priorizadas
y tareas a realizar. Por turnos cada uno va contestando:
– Qué hice ayer: la reunión de planificación, ¿no?
– Qué voy a hacer hoy: cada uno elige voluntariamente una o varias tareas a
las que va a dedicar el día, con el foco siempre de tratar de aportar lo más
posible al equipo. Es un compromiso delante de tus compañeros.
– Qué impedimentos tengo: el Scrum Master toma nota de todos los

problemas que se prevean para tratar de solventarlos cuanto antes
 Y cada uno se marcha a su sitio y comienza a trabajar en su tarea.

Comunicación constante cara a cara con el resto del equipo, Product
Owner siempre a mano para preguntarle dudas… Agilizando el
proceso todo los posible
 Es habitual utilizar salas de reuniones, pizarras, flipcharts, etc. para

que los miembros del equipo que quieran se reúnan espontáneamente
y decidan temas de diseño del producto, enfoque general,
interdepencias entre tareas, etc.

Seguimiento del Sprint
 ¿Cuál es la mejor forma de realizar el seguimiento del Sprint, y
saber si vamos avanzando a buen ritmo?
 Un recomendación es utilizar un panel en una de las paredes de
la sala
 En él se colocan físicamente las tarjetas que describen las
historias, y las tareas necesarias para realizarlas. Cada tarea
puede estar únicamente en tres estados:
 Aún sin comenzar
 Trabajando sobre ella
 ¡Hecha!
 Estas tres columnas y un gráfico burn-down suelen ser

suficientes para medir el avance del Sprint. Veamos cómo sería
un panel de un Sprint con dos historias.

SPRINT 4: TERMINAR MÓDULO GESTIÓN COMERCIAL
PENDIENTE TRABAJANDO… ¡HECHO!

Burn-down
15 ALTA DE PEDIDO
productos del catálogo, seleccionar
modo de pago. Comprobar la creación 20
Solicitante Estimación
Yolanda Córdoba – Dpto. Ventas
Categoría 5
Módulo Ventas
Mostrar Generación
productos número Pruebs y
catálogo pedido debug
Calcular errores
importe
pedido +
impuestos
15
16 INFORME
ALTA DEPEDIDOS
PEDIDO
Elegir
Elegir
informe,
cliente,
filtrar
seleccionar
por criterios,
dos
productos
obtener listado
del catálogo, seleccionar
20
30
modo de pago. Comprobar la creación
del pedido y asignación número pedido. Imprevistos Si sobra tiempo…
Solicitante Estimaci ón
Yolanda Martínez
Rodrigo Córdoba
ó – Dpto. Ventas 15
17 MODIFICACION
ALTA DE PEDIDO
DE PEDIDO
Categoría 5
8 C ó mo se prueba Prioridad
Módulo Ventas Elegir un
cliente,
pedido,
seleccionar
cambiar datos
dos
De productos,
productos del cat ácomprobar que sale
logo, seleccionar
modocorrectamente
de pago. Comprobar la creaci ón 20
60
del pedido y asignaci ón n ú mero pedido.
Mostrar
Filtrado Calcular Solicitante Estimaci ón
Generaci ó n
campos
productos importe
Listado+pdf nListado
ú mero html Yolanda C órdoba – Dpto. Ventas
cat á logo pedido
pedido
impuestos
Categor ía 5
2
Mó dulo Ventas


Burn-down
15 ALTA DE PEDIDO
Categoría 5
Módulo Ventas
Mostrar Generación
productos
Calcular número
catálogo
importe pedido Pruebas y
pedido + debug
impuestos errores
15
16 INFORME
ALTA DEPEDIDOS
PEDIDO
Elegir
Elegir
informe,
cliente,
filtrar
seleccionar
por criterios,
dos
productos
obtener listado
20
30
Yolanda Martínez
Rodrigo Córdoba
17 MODIFICACION
ALTA DE PEDIDO
DE PEDIDO
Categoría 5
cliente,
pedido,
seleccionar
cambiar datos
dos
De productos,
logo, seleccionar
modocorrectamente
60
Filtrado
campos Calcular Solicitante
Generaci ó n Estimaci ón
importe Listado
Listado +pdf nú mero html Yolanda C órdoba – Dpto. Ventas
pedido
pedido
impuestos
Categor ía 5
2
Mó dulo Ventas
A medida que el equipo emprende las tareas, se van moviendo hacia la derecha


Burn-down
15 ALTA DE PEDIDO Mostrar
productos
Calcular
Cómo se prueba Prioridad importe
catálogo
pedido +
impuestos
modo de pago. Comprobar la creación 20 Generación
número
del pedido y asignación número pedido. pedido
Categoría 5
Módulo Ventas
Pruebas y
debug
errores
Filtrado
15
16 INFORME
ALTA DEPEDIDOS
PEDIDO campos

Elegir
Elegir
informe,
cliente,
filtrar
seleccionar
por criterios,
dos
productos
obtener listado
20
30
Yolanda Martínez
Rodrigo Córdoba
17 MODIFICACION
ALTA DE PEDIDO
DE PEDIDO
Categoría 5
cliente,
pedido,
seleccionar
cambiar datos
dos
De productos,
logo, seleccionar
modocorrectamente
60
Calcular Solicitante Estimaci ón

Generaci ó n
importe Listado
pedido
pedido
impuestos
Categor ía 5
2
Mó dulo Ventas
Y a medida que se finalizan completamente, se trasladan a ¡Hecho!


Burn-down
15 ALTA DE PEDIDO
Categoría 5
Módulo Ventas
Mostrar Generación
productos
Calcular número
catálogo
importe pedido Pruebas y
pedido + debug
impuestos errores
15
16 INFORME
ALTA DEPEDIDOS
PEDIDO
Cómo se prueba Prioridad Si a lo largo del Sprint se
realizan tareas no
Elegir
Elegir
informe,
cliente,
filtrar
seleccionar
por criterios,
dos
productos
obtener listado
20
30
previstas inicialmente, se Imprevistos Si sobra tiempo…
Solicitante
Yolanda Martínez
Rodrigo Córdoba
ó – Dpto. Ventas
Estimaci ón
anotan aquí 15
17 MODIFICACION
ALTA DE PEDIDO
DE PEDIDO
Categoría 5
Listado html
cliente,
pedido,
seleccionar
cambiar datos
dos
De productos,
logo, seleccionar
modocorrectamente
60
Filtrado
campos Calcular Solicitante
Generaci ó n Estimaci ón
importe Listado
pedido
pedido
impuestos
Categor ía 5
2
Mó dulo Ventas
Listado html
Y si terminamos las historias

previstas antes de finalizar el
Sprint, emprenderemos la
siguiente que hubiera en este
apartado

 El gráfico Burn-Down se actualiza diariamente, según el trabajo realmente
avanzado.
Trabajo que El primer día de trabajo no

falta (en puntos avanzamos nada, y siguen Por tanto una línea por
quedando 50 puntos por debajo de lo previsto
de historia) hacer
50 indica un avance, por
El segundo día va estupendamente y encima indica un
terminamos 20 puntos: quedan 30
40 retraso
30 El tercer día avanzamos 5

puntos más: quedan 25
20
10
En principio pensamos
terminar 50 puntos de
1 2 3 4 5 6 Días del Sprint
historia en 6 días

¿Cómo actualizamos el panel? Daily Scrums
 Normalmente, el panel anterior es suficiente para tener un “feeling”
de cómo va el Sprint de un solo vistazo: qué hay que hacer, qué está
en marcha, cuántos imprevistos han surgido, si vamos por encima o
por debajo del burn-down…
 El panel se actualiza diariamente tras el daily scrum, o reunión

diaria, recordemos:
– Qué hice ayer: cada miembro expone brevemente si consiguió los

objetivos del día anterior, y desplaza físicamente las tarjetas hacia la
derecha del panel. Actualiza también la estimación de trabajo restante
de cada tarea (¿simplemente resto un día, o nos habíamos equivocado
en la estimación inicial?
– Qué haré hoy: elige las tareas del día (puede escribir su nombre en los
post-it), y las mueve hacia la derecha si es necesario
– Impedimentos: como siempre, qué problemas estoy teniendo o puedo

tener

¿Cómo actualizamos el panel? Daily Scrums
 De los comentarios surgidos en la reunión, se va actualizando la foto final
del panel: se mueven las tareas realizadas hacia la derecha, se agregan
post-its de tareas imprevistas, se elige la siguiente historia si ya se han
terminado todas…
 Si alguna de las tareas sufre una variación en la estimación del trabajo

restante, se puede sobreescribir directamente en el post-it:
Filtrado campos ¡Ojo! Esto nunca varía los puntos de historia

estimados inicialmente para esta historia. Aquí
tendremos una desviación entre lo calculado
inicialmente y la realidad final, que nos
2 días ayudará a estimar mejor la próxima vez.
4 días
 A medida que se avanza en el trabajo, las estimaciones del trabajo que queda en
cada tarea decrecen en lugar de crecer (¡esperemos!) – cuando todos han
comentado sus tareas del día anterior, se suman las estimaciones del trabajo que
queda y se actualiza el burn-down

Un apunte sobre equipos auto-organizados
 Recordemos que en Scrum hablamos de equipos auto-organizados:
– No es el Scrum Master el que reparte las tareas: “Tú haces la historia

15, tú terminas hoy esta tarea…”
– Cada miembro del equipo elige individualmente a qué se va a dedicar
ese día, cómo puede ser más útil para que el equipo consiga sus fines
– El Scrum Master es el encargado de eliminar los impedimentos
detectados por el equipo: él se encarga de que nada interfiera con el
progreso previsto
 Este enfoque ocasiona que:
– Los miembros del equipo están mucho más comprometidos con los
resultados: si yo mismo dije ayer que el equipo podía confiar en que
terminara la tarea X, haré lo posible por no tener que desdecirme
– Existe mayor espíritu de cooperación: si un miembro del equipo se
enfrenta a un problema, el resto voluntariamente hará lo posible por
ayudar. No existen éxitos o fracasos individuales, es todo el equipo el
que triunfa o falla
– Hay que acostumbrarse a este nuevo enfoque: resulta mucho más
cómodo que mi jefe me diga qué hacer, que ser yo mismo el que tenga
que decidir dónde puedo aportar más

Un apunte sobre equipos auto-organizados
 Una vez descritas las historias, el equipo decide cómo

llevarlas adelante. No hay jefes, no hay analistas que se
encierran a pensar mientras los programadores esperan sus
conclusiones: en los equipos multidisciplinares, cualquier
miembro puede tener que hacer cualquier tarea si las
circunstancias lo requieren
 Normalmente, el equipo se reunirá frente a una pizarra en
blanco, y de forma conjunta empezará a esbozar el diseño de
las primeras historias. ¿Se documenta posteriormente el
diseño de una forma más ortodoxa? Depende. ¿Va a ser útil
hacerlo, aporta algún valor al producto final, el uso que se
haga de él va a ser mayor que el tiempo empleado en
hacerlo? Entonces sí. Pero si todos tenemos claro el diseño,
sabemos qué hay que hacer, y no aporta nada documentarlo,
¡a programar!

¿Qué aspecto tiene?

Ha terminado el tiempo previsto del Sprint…
 Por fin llega la fecha fin del Sprint, el día en que se

supone que están todas las historias terminadas y
funcionando correctamente. ¿Cómo lo demostramos?
– Mediante la demo del Sprint

Reunión de demo del Sprint
 Recordemos: en la reunión de planificación inicial se fija

ya fecha y lugar de la demo del Sprint
 Es una reunión abierta en la que se demostrará la
funcionalidad del producto, es decir, repasaremos las
historias comprometidas en el Product Sprint y
probaremos que efectivamente funcionan (¡esperemos!)
 Algunas preguntas básicas:
– ¿cuánto dura?
– ¿quién asiste?
– ¿quién la realiza?
– ¿qué objetivo se persigue?

¿Qué conseguimos con la demo?
 Si va todo bien:
– Los stakeholders tienen una visión real del grado de
avance del producto, comprueban de primera mano la
funcionalidad existente
– Pueden ajustar sus prioridades e historias para el
siguiente sprint, a partir de lo visto en la demo
– Es una inyección de moral para el equipo, que puede
demostrar el resultado de su (duro) trabajo y “palpar”
el progreso

Tras la demo…
 Hay quien recomienda dejar un día de descanso, auto-

estudio, etc. tras la demo. Normalmente el equipo
terminará cansado tras el esfuerzo final, y es positivo
tener un día más relajado en la oficina para leer
documentación técnica, ponerse al día de mails
atrasados, enterarse del estado de otros proyectos, y
hacer vida en común
 Antes de empezar con el siguiente Sprint, en Scrum se
realiza una reunión llamada retrospectiva: veamos qué
hemos aprendido en este Sprint para no cometer los
mismos errores en el siguiente…

Retrospectivas
 La retrospectiva es un elemento clave dentro del Scrum
– Reunión final tras la demo en la que analizamos críticamente qué tal lo

hemos hecho
– Como siempre, time-boxing: 30-60 minutos
– Participan todos: equipo, Product Owner, Scrum Master, invitados
– Todos los miembros del equipo tienen la oportunidad de opinar sobre los
puntos fuertes y débiles del Sprint recién terminado
– A partir de ahí, se eligen por consenso los puntos de mejora en los que
se trabajará durante el próximo Sprint, y cada persona decide a cuál de
ellos se va a dedicar
 Hay muchas maneras de realizar una retrospectiva, una de ellas es

contestar a:
– Qué nos gustaría empezar a hacer (que el Product Owner esté accesible
en su móvil)
– Que nos gustaría dejar de hacer (agrupar todos los bugs de Sprints
anteriores en una sola historia, los bugs más críticos deberían ser una
historia en sí mismos)
– Que nos gustaría continuar haciendo (traer bizcochos a los daily scrums)

Retrospectivas
 Otra sencilla herramienta para obtener información y favorecer el diálogo:
 
 Mejoró comunicación con  Salimos tarde 4 días
Nos gustó… Product Owner No nos
gustó…
 
Nos  Invitar a Juan Cervera a  Alfredo por introducir la Se merece
gustaría… la demo del Sprint nueva herramienta de un regalo…
testeo

Retrospectivas
 ¿Cómo decidimos sobre qué iniciativa de mejora trabajará
cada uno?
– Que sea cada miembro del equipo el que elija, como siempre
 Una posibilidad es escribir las mejoras acordadas en distintas

tarjetas. Cada miembro tiene tres fichas, y puede colocarlas
sobre la mejora/s en la que más le interesa trabajar (pueden
ser las tres fichas en la misma)
 Obtenemos una lista de mejoras y personas asignadas para
promoverlas. En la siguiente retrospectiva se revisará su
estado.
 ¿Qué ocurre si nadie quiere trabajar sobre un tema?
– Será que no es tan importante…
– Pensemos entre todos una forma de incentivar su acometida

Scrum fallará si…
Cliente: “Ya os he contado lo que quiero, así que no me volváis a

molestar hasta que no esté listo”
Desarrollador: “Yo haré lo que mi jefe me diga que tengo que

hacer”
Jefe proyecto (o “control freak”): “¡Necesito estimar costes y plazos

finales!”
Todos: “Bah, como es un enfoque más relajado no pasa nada por

que nos saltemos un par de puntos, ¿no?”

Comparativa

Métricas SCRUM (INICIALES)
Calculadas al principio del sprint
A. Velocidad objetivo: suma de los "story points" de todos los items de

la pila del producto inicialmente incluidos en el sprint.
B. Horas estimadas: suma de las estimaciones en todos los post-its
amarillos al principio del sprint. Es el primer valor a dibujar en el
gráfico de burn-down.
C. Horas diponibles: total de horas·hombre disponibles para el sprint.
D. Factor de foco objetivo (B/C): como un %

ESTADÍSTICAS FINALES
(calculadas al terminar el sprint)
E. Velocidad real: suma de los "story points" realmente completados en el sprint
F. Horas reales: número real de horas dedicadas al sprint (eso es: C - bajas médicas y similares + horas
extras si las hubiera)
G.Total estimaciones tareas previstas en sprint completadas: suma de las estimaciones iniciales de los
post-its amarillos y azules que realmente completamos. Eso es: B + post-its azules - trabajo excluído del
sprint.
H. Factor de foco (G/F): como un %
J. Horas cargadas a tareas planeadas: recuento de todas las horas reportadas en todos los post-its
amarillos y azules completados en el sprint. Este es el más pesado de calcular, pero no son más de dos o
tres minutos por sprint, así que deja de gimotear. Incluso mi hija de 9 años puede sumar eso sin
necesidad de un ordenador.
K. Horas cargadas a tareas no planificadas "dentro del sprint"
L. Error de estimación ((J+K)/G-1): como un %
M. Factor de foco real ((J+K)/F): como un %
N. Horas cargadas a tareas no planificadas "fuera de sprint": con frecuencia se descomponen en
categorías tales como bugfixes, soporte, operaciones, publicidad,...
P. Total de horas cargadas (J+K+N)
Q. Error de reportado (1-P/F)

Objetivo de las Métricas
Muchas métricas pero nos permiten dilucidar, cuando hay problemas de
planificación, si fue por un exceso de trabajo no planificado,
estimación inválida (hubo tareas que no supimos identificar), o
estimación imprecisa. Los dos últimos valores (P y Q) son solo un
"checksum" para alertarnos si dejamos de reportar las horas
adecuadamente.

Herramientas Scrum
- Kunagi. (http://kunagi.org/)
Herramienta Web que proporciona un sistema de gestión de proyectos basado en Scrum. Ofrece
herramientas colaborativas y otras facilidades, como un cuadro de mando del proyecto, un panel
interactivo para el Sprint o soporte a la estimación con Planning Poker.
- ScrumDo. (http://www.scrumdo.com/)
Herramienta Scrum muy centrada en la simplicidad y en la facilidad de uso. Permite gestionar las
listas de tareas e historias de usuario, crear y gestionar iteraciones, obtener gráficos de avance
“burndown” y también dar soporte a la estimación con Planning Poker.
- SprintoMeter. (http://sprintometer.com/)
Herramienta para la gestión, medición y seguimiento de proyectos Scrum y eXtreme Programming.
Para simplificar el intercambio de datos permite exportar gráficos e informes a Excel. Posee gráficos
de avance burndown en 3D.
- IceScrum. (http://www.icescrum.org/)
Herramienta Scrum y Kanban. Ofrece las opciones de operación, consulta y estimación de historias
de usuario. Permite añadir historias de usuario a la pila de producto, dividir el tiempo en Sprints y
mover estas historias de la pila de producto a cada uno de los Sprint. Posee la técnica de Planning
Poker para la estimación y paneles virtuales.
- Pango Scrum. (http://pangoscrum.com/)
Otra de las herramientas Scrum online, con una interfaz sencilla y amigable que permite escribir,
estimar y priorizar la pila de producto. Facilita en gran medida la planificación de Sprints y las
reuniones.

Resumen de Herramientas SCRUM
http://www.opensourcescrum.com/

Tema 3 y 4. Componentes. Técnicas y
Herramientas para la Construcción de
1
Ecosistema de
aplicaciones móviles.
2
Ecosistema de aplicaciones móviles.
Por ecosistema móvil nos referimos al conjunto de actores necesarios para poder
tener los dispositivos móviles y a las aplicaciones para los mismos. En concreto, en el
ecosistema móvil se incluyen las operadoras de telecomunicaciones, los fabricantes de
hardware y todos los elementos de software que intervienen en la ejecución de la
aplicación.
Todas las aplicaciones se ejecutan dentro de un ecosistema. Por lo tanto, para

conseguir un desarrollo satisfactorio, es ideal conocerlo.
Existen varios factores que afectan al ecosistema, como la infraestructura de la
aplicación, el sistema operativo, los métodos de entrada de información, los propios
usuarios, los canales de distribución de la aplicación, etc.
El amplio ecosistema de las aplicaciones

móviles constituye una de las mayores
dificultades en lo que respecta al desarrollo
de aplicaciones, ya que acaba causando,
entre otras cosas, una mayor
fragmentación de la aplicación. El
desarrollador debe tener en cuenta muchos
factores para que la aplicación funcione
como desea.

Fragmentación
La fragmentación es una situación, o el conjunto de condicionantes de

una situación, en la que no es posible compartir una misma aplicación
entre diferentes ecosistemas. Es decir, la fragmentación impide que se
pueda compartir la aplicación sin adaptar los ecosistemas.
Uno de los principios básicos para desarrollar aplicaciones consiste en intentar

tener el código más simple posible, de manera que se reduzca la complejidad,
se eviten los posibles errores y se facilite el mantenimiento. Esto ha resultado
muy difícil debido a la fragmentación, que existe en los entornos de
aplicaciones conocidas

Causas de la Fragmentación
 Hardware diferente: Como, por ejemplo, dispositivos con componentes distintos: tamaño o
densidad de la pantalla, teclado, sensores, capacidad de proceso, etc.
 Software Diferente:
 Plataforma diferente. Una plataforma, un framework, un sistema operativo (o las
versiones de cualquiera de ellos) puede generar la fragmentación de las
aplicaciones.
 Diferencias en las implementaciones. Por ejemplo, diferencias en la
implementación del estándar, o bien errores conocidos de versiones concretas.
 Variaciones de las funcionalidades. Por ser una versión con menos privilegios (versión de
pago y versión gratuita) o según los roles de los propios usuarios de la aplicación.
 Preferencias de usuario. Las más habituales son las localizaciones de la aplicación (idioma,
orientación del texto, etc.).
 Diversidad del entorno. Derivado de la infraestructura, como pueden ser los operadores y
sus API, los problemas de cortafuegos, las limitaciones de las redes, el roaming, etc.
La fragmentación puede afectar a todo el proyecto de desarrollo,

desde el modelo de negocio hasta el despliegue, además de la
implementación y las pruebas. Es imprescindible tratarla muy
seriamente.

Añadir
plataformas

Problemas de la Fragmentación
 Reducir la calidad del producto. Debido a la mayor
complejidad de las soluciones fragmentadas, se pueden
generar más errores.
 Limitar el número de dispositivos soportados. Para
evitar este problema, se puede decidir soportar un número
menor de dispositivos (con posibilidades de ampliaciones en
un futuro).
 Alargar cualquier fase del proyecto, desde las fases
iniciales a la implementación, además del mantenimiento.
Esta dilatación en el tiempo supondrá un sobreprecio, así
como posible fracaso de dicho proyecto.
 Grandes costes asociados a las pruebas sobre
dispositivos reales.

Fragmentación. Soluciones
Un desarrollo para cada escenario
Se realiza todo un desarrollo (portar la aplicación) para cada
fragmentación que nos podamos encontrar, sin compartir nada. Esto
suele ser útil en los casos en que los escenarios son muy diferentes.
Esta estrategia es la más costosa de

todas, pues no se puede aprovechar
nada (o casi nada) sin adaptaciones del
código realizado en otros escenarios.
Sin embargo, podemos aprovechar al
máximo la capacidad del dispositivo y
del lenguaje, así como las últimas
novedades.

Parte común y derivaciones
La derivación es la estrategia más habitual. Según esta estrategia, una
parte de nuestra aplicación es común a todos nuestros escenarios, y para
cada uno de ellos podemos definir la parte específica correspondiente.
 Derivación selectiva. Las modificaciones necesarias están localizadas en unos elementos concretos
(ya sean clases del código, ficheros de marcado, estilos u otros recursos), y existe un sistema o
herramienta que genera las diferentes versiones mediante la captura y el empaquetado de estos
elementos para cada escenario.
 Derivación usando meta programación. Se trata de programar algo que se va a ejecutar en varios
escenarios. Para conseguir distintos comportamientos hay varias opciones:
 Mediante la inyección de objetos o recursos (imágenes, ficheros XMLS, etc.) en el código, de

manera que nuestra aplicación deje estos objetos vacíos y se rellenen, en tiempo de
ejecución, los objetos específicos de cada escenario. Esta estrategia se basa en el patrón de
diseño Inversion of control.
 Utilizando preprocesadores, que se encargan de cambiar o ampliar nuestro código para

adaptarlo a los diferentes escenarios antes de ejecutar.
 Generación automática. El software se debe escribir de una manera específica y solo una vez. A
posteriori, existe un proceso que genera automáticamente las aplicaciones correctas para cada
escenario, normalmente transformando nuestra aplicación al código particular de cada escenario. En
este punto existen más variantes.

Adaptación única
Mediante la adaptación única, podemos conseguir una versión que funcione en todos los
casos sin necesidad de realizar más cambios. Existen varias maneras de afrontar esta
estrategia:
 Mínimo común denominador. Se trata de conseguir una aplicación mediante la

reducción de los puntos de fragmentación, de manera que no exista la necesidad de
adaptar la aplicación.
 Todos en uno.
 La aplicación es capaz de conocer la información necesaria para poder
adaptarse a todos los dispositivos. Por ejemplo, para evitar el problema de
diferentes pantallas, se genera una aplicación con ventanas autoescalables.
 Son los dispositivos los que se adaptan; es decir, el software se escribe de
manera abstracta y, cuando se llega al problema de la fragmentación, se pasa
el testigo al dispositivo que sabe cómo tratarlo. Un ejemplo puede ser el
acceso a los contactos o a las llamadas de teléfonos mediante API abstractas.

Resumen:

Otros Componentes a considerar en
el Diseño de Sistemas Móviles
Contexto
El contexto se define como las informaciones conjuntas de la situación
actual, el usuario, la información del dispositivo y la información de
otras aplicaciones en un momento dado del tiempo.
Las aplicaciones móviles pueden aprovechar mucho más el contexto en el que

están ejecutando, sobre todo si las comparamos con aplicaciones tradicionales.
Esto se debe a diferentes factores, entre los que se encuentran las nuevas
capacidades de los dispositivos, la capacidad de acceder a la información
que el propio dispositivo tiene del usuario (incorporando, de esta manera, las
capacidades o relaciones sociales del mismo) y las capacidades que puede
aportar el entorno en el que estamos o el momento en que usamos la
aplicación.

Contexto. Capacidades de los dispositivos
Los nuevos dispositivos nos aportan mucha información sobre nuestro
entorno.
Muchas de las aplicaciones aprovechan varias capacidades. Por ejemplo, una

aplicación de realidad aumentada aprovecha varias de ellas:
 GPS, para conocer la posición geográfica y saber qué se debe

mostrar.
 Brújula, para saber la orientación actual
 Acelerómetro, para saber cuál es la orientación exacta de nuestro
dispositivo y superponer las capas.
 Cámara, para poder captar nuestro alrededor y así ampliar la
información (en ocasiones, incluso, varias cámaras).
 Conexión a Internet, para poder obtener la información para ampliar
nuestra realidad. Esta conectividad puede venir mediante Internet
móvil o WiFi, entre otros.
 Capacidad de procesamiento gráfico muy mejorada, con chips de
aceleración gráfica potentes.
 ... NFC, RFID, etc.

Contexto. Ubicuidad
La ubiquidad (o la omnipresencia) se define como la capacidad de
acceder a toda la información o a todos los servicios que
necesita el usuario en cualquier momento y circunstancia mediante
el dispositivo que tengamos actualmente.
Beneficios:
 El dispositivo móvil es el primer medio de comunicación
masivo real, dado que es capaz de llegar a casi todos los
usuarios y en todo momento.
 El primer medio de comunicación permanentemente
encendido, pues es capaz de captar y enviar información aun
cuando está apagado (apagado en el sentido del usuario, es
decir, cerrado, pero no totalmente apagado).
 Primer medio que está siempre con el usuario.
 Medio masivo que tiene incorporado un sistema de pago,
que en este caso es mediante la operadora.

Contexto social
Significa la posibilidad de interaccionar mediante nuestras
aplicaciones con nuestros amigos, nuestra familia y otros conocidos
(o incluso desconocidos).
 Compartir nuestra puntuación en un juego.
 Ver usuarios que están actualmente interaccionando con la
aplicación, o bien con el tema que nos interesa en ese
momento (por ejemplo, poder comentar una serie de televisión
mientras la vemos).
 Publicar en cualquier momento lo que se estamos haciendo y
ver lo que hacen nuestros amigos.
 Recibir avisos de cuando nuestros amigos están cerca, llegan
a un lugar concreto o hacer alguna acción destacable.

Contexto Coste
Que la aplicación esté contextualizada es un gran punto a favor, pero
como toda aportación, tiene unos costes.
 Acceso a Internet mediante redes WiFi o MWWAN.
 Proximidad de otros dispositivos para compartir información.
 Estar constantemente conectado a las redes sociales, lo que requiere que dispongamos de
cuentas en esas redes sociales y que tengamos activado el acceso (con los posibles
problemas de privacidad).
 Conexiones a otras redes inalámbricas, Bluetooth, GPS, NFC, etc.
 Grandes capacidades de proceso en nuestros teléfonos para realizar las acciones, ya sea la
capacidad de proceso interno o bien mediante accesorios.
 Debido a innovaciones y cambios, tenemos que pagar el coste de actualizar nuestra
aplicación. Es decir, durante o después del lanzamiento de nuestra aplicación, pueden
aparecer nuevas fuentes de fragmentación hardware o software que provoquen que nuestra
aplicación se tenga que actualizar.
Limitación de Vulnerabilidad de Necesidades

la vida de las la privacidad. de hardware
baterías.
Necesidades de inversión no previstas
debido a novedades del merca

Características de un
proyecto de
desarrollo para
dispositivos móviles
18
Tipos de aplicaciones
Aplicaciones básicas
La aplicaciones básicas son aplicaciones de interacción básica con el
dispositivo que únicamente envían o reciben información puntual del
usuario.
Ventajas:
 simplicidad
 Facilidad de venta
 gran cantidad de usuarios potenciales
Desventajas:
 poca o casi nula capacidad de procesamiento del contexto
 muy baja complejidad de las aplicaciones realizadas
 limitaciones impuestas por la tecnología sobre los diseños de las
aplicaciones (ciento sesenta caracteres de texto)

Webs móviles
Las webs móviles son aquellas webs que ya existen actualmente y que son adaptadas
específicamente para ser visualizadas en los dispositivos móviles. Adaptan la estructura
de la información a las capacidades del dispositivo, de manera que no saturan a los usuarios y
se pueden usar correctamente desde estos dispositivos.
Ventajas:
 Fácil implementación, testeo y actualización. Incluso se puede realizar gran parte del desarrollo sin
necesidad de utilizar dispositivos móviles ni emuladores, hasta llegar a las fases finales del desarrollo.
 Lenguaje conocido y estándar. Los lenguajes de marcas son muy conocidos hoy en día por la mayoría de
los desarrolladores, y en la mayoría de los casos se trata de subconjuntos de lenguajes conocidos.
 Pueden soportar múltiples dispositivos con un único código fuente. Para soportar fragmentación entre
dispositivos, es necesario utilizar técnicas especiales (como el WURLF).
Desventajas:
 Es difícil soportar múltiples dispositivos, así como conseguir la misma experiencia
de usuario con varios tipos de navegadores.
 Ofrecen grandes limitaciones a la hora de realizar programas, tanto de proceso
como de acceso a la información del dispositivo y del usuario. Por tanto, es difícil
conseguir aplicaciones contextualizadas.
 En muchos casos está pensado para ser visualizado con conexiones lentas, pero
dichas conexiones pueden ser demasiado lentas y provocar una experiencia de usuario
deficiente.
 En la actualidad, la mayoría de los dispositivos nuevos están incorporando estándares
más nuevos (como HTML 5), por lo que no se está trabajando en mejorar estos
estándares.
 El número de dispositivos que solo pueden ver una página web con este tipo de
lenguajes de marcas está disminuyendo.

Aplicaciones web sobre móviles
Las aplicaciones web sobre móviles son

aplicaciones que no necesitan ser
instaladas en el dispositivo para poder
ejecutarse. Están basadas en
tecnologías HTML, CSS y Javascript, y
que se ejecutan en un navegador.
A diferencia de las web móviles, cuyo

objetivo básico es mostrar información,
estas aplicaciones tienen como
objetivo interaccionar con el
dispositivo y con el usuario. De esta
manera, se le saca un mayor partido a
la contextualización.
Ejemplo: aplicaciones en sobremesa, que

han sido rápidamente portadas:
dismobile.twitter.com, facebook.com,
maps.google.com, etc.

Aplicaciones web sobre móviles. HTML 5
 Añadir novedades al HTML y CSS actuales.
 Dar soporte a todos los navegadores, incluyendo los navegadores móviles, evitando
una ruptura total con las versiones actuales del estándar.
 Aprovechar las características de los dispositivos actuales, como pueden ser
aceleración gráfica o múltiples procesadores.
 Tener mayor libertad de desarrollo, evitando al máximo la necesidad de extensiones
propietarias que existen actualmente.
 Visualización de información e interacción con dicha información más potente, a
través de los lienzos (canvas) y los formularios (web forms). En los formularios se
tiene validación nativa del navegador.
 Modo sin conexión. Guardado de la información del usuario en el dispositivo físico,
mediante el almacenamiento local para por ejemplo soportar falta de conectividad.
 Almacenamiento de datos en el navegador como una base de datos.
 Acceso a datos como la posición geográfica.
 Renderización de objetos gráficos aprovechando la potencia de las tarjetas
gráficas de los dispositivos, para así mejorar su rendimiento (gracias en parte al
soporte de SVG6).
 Soporte para video y audio (etiquetas <video> y <audio>) sin necesidad de
extensiones propietarias.
 Nuevas etiquetas semánticas, como section, article, header, nav, etc.
 API para coger y arrastrar (Drag & drop).
 Trabajos pesados en segundo plano (Web Workers).

Aplicaciones web sobre móviles
Ventajas:
 Posibilidad de acceso a mucha información del dispositivo para realizar
aplicaciones relativamente complejas.
 Desarrollo, distribución y pruebas sencillas.
 Convergencia entre aplicaciones de sobremesa y de dispositivos móviles, lo
cual tiene muchas implicaciones, como, por ejemplo, que los desarrolladores solo
tienen que conocer una tecnología.
 Uso de estándares de la web (claramente definidos).
 Ampliamente soportado por la industria, de manera que la mayoría de los
nuevos dispositivos tienen soporte para este tipo de aplicaciones.
Desventajas:
 Se necesita un navegador que pueda dar soporte a este tipo de
tecnología. Aunque la mayoría de los nuevos dispositivos lo pueden
dar, los antiguos no.
 Su rendimiento es menor con respecto a las aplicaciones nativas,
pues se ejecuta todo mediante el Javascript del navegador, cuya
potencia es limitada.
 Imposibilidad de acceder a todas las posibilidades del
dispositivo. No se puede acceder al hardware ni a muchos
periféricos (como sensores o cámaras). No se puede acceder a
mucha de la información del usuario (contactos, sus citas, etc.).

Aplicaciones web móviles nativas
No son aplicaciones web propiamente ni tampoco nativas. Se ejecutan con un
navegador o, mejor dicho, con un componente nativo que delega en un navegador, y
tienen algunas de las ventajas de las aplicaciones nativas.
Simplemente ejecutan código en un navegador embebido (generalmente con HTML
5).
Ventajas:
 Todos los puntos a favor de las aplicaciones web móviles.
 Se pueden considerar, en lo que respecta a la instalación y la distribución,
como aplicaciones nativas.
Desventajas:
 La mayoría de los inconvenientes de las aplicaciones web
móviles, a excepción de la instalación en el cliente.
 La experiencia del usuario es, en ocasiones, contradictoria, pues
a pesar de tratarse de una aplicación nativa, requiere de conexión
a Internet para poder trabajar y funciona según los tiempos de
respuesta del navegador.
Ejemplo:Aplicaciones de acceso a información confidencial, como son las entidades
financieras "en línea", que distribuyen la aplicación, pero por su naturaleza no es
recomendable que haya datos en el dispositivo físico.

Aplicaciones nativas
Las aplicaciones nativas son las aplicaciones propias de cada plataforma. Deben ser
desarrolladas pensando en la plataforma concreta. No existe ningún tipo de
estandarización, ni en las capacidades ni en los entornos de desarrollo, por lo que los
desarrollos que pretenden soportar plataformas diferentes suelen necesitar un esfuerzo
extra.
Ventajas:
 Acceso total al contexto, con todas las posibilidades que eso conlleva. Consigue las
mejores experiencias de usuario.
 Posibilidad de gestión de interrupciones en la aplicación o en las capacidades del
dispositivo. Desde saber si tenemos conexión de datos o conexión de localización
hasta tener información sobre la batería.
 Son relativamente fáciles de desarrollar si solo se contempla una plataforma.
 Se pueden distribuir por los canales conocidos de aplicaciones que permita la
plataforma, con lo que se pueden vender más fácilmente.
 Todas las novedades llegan primero a este tipo de aplicaciones, pues es en este
tipo de aplicaciones donde se prueban.
Desventajas:
 Portar aplicaciones es costoso. En el caso de querer realizar una aplicación para más de una
plataforma, se complica el desarrollo, debido a los problemas de la fragmentación.
 Dependiendo de la plataforma elegida, puede haber fragmentación dentro de cada plataforma,
debido a los diferentes tipos de dispositivos o versiones de la plataforma.
 No existe un estándar, por lo que cada plataforma ofrecerá sus peculiaridades.
 Normalmente, para desarrollar, distribuir o probar estas aplicaciones en dispositivos reales, es
necesario tener una licencia de pago, dependiendo de la plataforma.
 Las ganancias por estas aplicaciones suelen repartirse entre el creador de la aplicación y la
plataforma de distribución.

Estrategias de
desarrollo de
aplicaciones móviles
26
Estrategias de desarrollo de AM. Desarrollos web
Desarrollos web
Todas las aplicaciones que están basadas en lenguajes de marcas. Quedan excluidas
las aplicaciones que requieren de un preproceso para poder ser distribuidas.
Se incluyen además aplicaciones web basadas en aplicaciones propietarias, como, por
ejemplo, Flash y Flash lite. Estas aplicaciones tienen el mismo modelo de desarrollo.
Prerequisitos. En general, se puede utilizar cualquier entorno de desarrollo conocido.

En el caso de las aplicaciones de tipo widget o entornos de ejecución propietarios, los
fabricantes suelen dar soporte a estos desarrollos mediante entornos de desarrollo
específicos.
Fragmentación. La fragmentación en este tipo de aplicaciones existe, aunque suele

ser menor que en el resto. Para poder adaptar nuestra aplicación a las capacidades
del dispositivo, y dado que estamos en una arquitectura de navegador web, la mejor
opción es intentar reconocer el dispositivo cuando se recibe la primera petición.
Una vez que sabemos el dispositivo, tenemos que conocer sus capacidades.
a) Teniendo el conocimiento (por ejemplo, el proyecto WURLF, que consiste en

una base de datos de todos los dispositivos y sus capacidades).
b) Utilizando servidores que incorporen ese conocimiento y lo automaticen,
de manera que lleguen a realizar transformaciones automatizadas. Esta opción
tiene el inconveniente de que las últimas versiones no suelen estar soportadas.

Desarrollos web

Pruebas. Las pruebas se pueden empezar con navegadores de
escritorio que soporten HTML 5 o el correspondiente lenguaje de
marcado, pero después se deberán hacer pruebas reales, o bien con
emuladores. Hay que prestar especial atención a aquellas partes de
los estándares que no son soportadas por todos los dispositivos.
Distribución. La distribución es lo más sencillo, ya que es igual que la

distribución de una aplicación web cualquiera. Solo cuando haya
cambios incompatibles con los datos guardados "fuera de línea" de
una aplicación, habrá que realizar acciones informativas para que el
usuario actualice dichos datos.

Estrategias de desarrollo de AM. Entornos Nativos
Prerrequisitos. Para poder desarrollar una aplicación nativa, generalmente se necesita
el entorno de desarrollo o IDE de cada plataforma. Por ejemplo, para Android
necesitamos su SDK, y es recomendable usar Eclipse y añadirle algunos plugins. En
cambio, en el caso de iOS, necesitamos xCode; para Blackberry apps necesitamos
también su SDK; para Windows Phone necesitamos Miscrosoft Visual Studio, etc.
Estos IDE pueden tener una licencia de pago, la cual dependerá de cada
plataforma.
Implementación. Todas las implementaciones son distintas. Cada sistema utiliza su

propio método y sus propios patrones, pero hay algunos puntos comunes:
a) Existe un emulador con el que podemos probar nuestras aplicaciones. Sin
embargo, en ocasiones el emulador no permite emular todas las acciones de
usuarios o la emulación no es lo suficientemente ágil, por lo que necesitamos un
dispositivo real.
b) Separación de presentación y lógica, de manera que aprovechemos al máximo los
componentes.
c) Posibilidad de "depurar" nuestra aplicación para poder tener mayor control.
d) Generalmente existen herramientas que facilitan la construcción de las interfaces
gráficas o UI (user interface).

Estrategias de desarrollo de AM. Entornos Nativos
Pruebas. Para poder hacer pruebas, cada IDE tiene sus herramientas, desde
las típicas tecnologías de pruebas unitarias hasta sistemas más complejos,
como el monkeyrunner de Android. Para realizar pruebas de estrés de las
aplicaciones, también existen herramientas para hacer pruebas de
aceptación contra la UI, que utilizan lenguajes de alto nivel, como es el caso
de UIAutomation sobre iOs.
Firma y distribución. Para poder distribuir la aplicación o, incluso, ejecutarla

en un terminal para hacer pruebas, puede ser necesario firmar dicha
aplicación con un certificado digital que nos identifique como
desarrolladores.
Si la distribución se realiza mediante terceros, como sucede en los
mercados de aplicaciones (market places), es incluso más necesario para
poder acreditar que tenemos el derecho de publicar aplicaciones, así
como para hacernos responsables de dichas aplicaciones.
Según la plataforma, los modelos de distribución son simplemente
sistemas de descarga, bien mediante sistemas OTA (over the air), bien
mediante los mercados de aplicaciones.
Estrategias DAM. Entornos Multiplataforma
Aspectos difíciles de lograr:
Pérdida de controles específicos de una plataforma: Si tenemos un control de la UI o una funcionalidad
concreta que solo existe en una plataforma, no podremos generar de manera única, por nuestro desarrollo
multiplataforma.
Integración en el escritorio del dispositivo: Según la plataforma, las posibilidades de añadir elementos en
el escritorio de cada usuario varían. Por ejemplo, en Android o Symbian se pueden crear widgets potentes
para mejorar la el uso de nuestra aplicación, mientras que en Windows Phone solo es posible añadir
iconos de la misma.
Gestión de la multitarea: Debido a que se trata de conceptos de bajo nivel de cada plataforma, cada una la
trata de manera diferente, con restricciones diferentes, por lo que no será fácil hacer código común para
todas sin perder mucha potencia.
Consumo de la batería: Estas aproximaciones requieren de una capa de abstracción sobre nuestro
dispositivo, el control sobre el consumo de batería se hace más difícil cuando no se tienen las
capacidades concretas de la plataforma. También afecta el hecho de no tener el control sobre la
multitarea, ya que esta es una de las maneras de ahorrar las baterías.
Servicios de mensajería asíncrona o push services: Sirven para implementar elementos como la
mensajería instantánea, pero debido a que cada plataforma los implementa de una manera, se hace
complicado atacarlos conjuntamente.

Estrategias DAM. Entornos Multiplataforma
Ejemplos:
PhoneGap/Cordova: Son aplicaciones realizadas en HTML 5 con objetos Javascript
que permiten el acceso, mediante enlaces, a las funciones nativas para las
capacidades que HTML 5 no ofrece. Las aplicaciones se ejecutan sobre un
componente que contiene un navegador.
IONIC: Ionic es una herramienta, gratuita y open source, para el desarrollo de
aplicaciones híbridas basadas en HTML5, CSS y JS. Está construido con Sass
(extensión de CSS y optimizado con AngularJS. Se puede acceder a la capa nativa
usando los plugins de Cordova.
Rhodes: Son aplicaciones escritas en Ruby que utilizan el patrón de diseño MVC
(vista-controlador) y que se ejecutan en máquinas virtuales específicas de Ruby
para cada plataforma. Por tanto, son aplicaciones nativas. Incluyen sistemas para
sincronizar datos de manera sencilla y conseguir, de esa manera, el cambio de "en
línea" a "fuera de línea" sin mucho coste.
Appcelerator: Son aplicaciones escritas en HTML 5 que son compiladas en
aplicaciones nativas. También son capaces de generar aplicaciones de sobremesa
clásicas, ejecutables sobre Mac, Linux o Windows.

Estrategias DAM. Entornos Multiplatafotma
Ejemplos (II)
Wacapps: Son aplicaciones escritas en HTML 5 con soporte para la distribución por
parte de las operadoras.
Flash: Son aplicaciones que corren sobre un player propietario. Si existe el player
correspondiente, no necesitan ser portadas. Se escriben de igual manera que las
aplicaciones de sobremesa y tienen las mismas restricciones.
Java ME: Son aplicaciones escritas en Java, con todas las peculiaridades de los
perfiles J2ME, y se ejecutan mediante una máquina virtual, con sus
correspondientes restricciones. Actualmente están en casi el ochenta porciento de
los dispositivos móviles del mercado.
Unity3D: Entorno para desarrollar juegos nativos o web para cada plataforma, como
Play Station, Wii, PC, Mac, etc. También da soporte para las Android e Iphone.

Estrategias DAM. Entornos Multiplatafotma
Prerrequisitos. Para conseguir las aplicaciones nativas, cada uno de los
entornos proporciona su entorno de desarrollo completo. En muchos casos,
las aplicaciones se prueban en los emuladores de las plataformas nativas,
de manera que hay que instalar el IDE propio del entorno de desarrollo y
los emuladores o, en ocasiones, los SKD.
Implementación. Durante la implementación, variará mucho en función de

cada plataforma, pues hay algunas que podrán aprovechar todas las
herramientas de desarrollo, otras que no lo necesitarán en exceso y
algunas en las que el desarrollo será más difícil.
Firma y distribución. A veces la distribución se puede realizar

directamente mediante los IDE de las plataformas de desarrollo, pero en la
mayoría de los casos es necesario hacerla mediante los canales habituales
para las aplicaciones nativas.

Especificación y diseño
Especificación y diseño
Existen algunos patrones de diseño ampliamente conocidos en el desarrollo de
aplicaciones, que suelen ser implementados en las aplicaciones para dispositivos
móviles:
Model-View-Controler (MVC). Se utiliza para poder separar al máximo la lógica de la
visualización e interacción, y así poder dar soporte a más escenarios, como puede
ser el caso de una aplicación para smartphone y la misma para tablet PC.
Threading. Se refiere al uso de hilos en segundo plano para realizar tareas largas que
bloqueen al usuario.
Delegation. Se trata de delegar una parte del trabajo hacia otro objeto sin que este
tenga que ser una subclase del primero. En el caso de los desarrollos móviles, es
muy útil para delegar trabajos relacionados con la interfaz, de manera que pueda
trabajar con eventos de manera muy sencilla y sostenible.
Modelo de memoria gestionada. En general, las aplicaciones no se ejecutan
directamente sobre la plataforma, sino que suele haber una capa intermedia o
middleware, y esta suele gestionar la memoria. Sin embargo, para poder hacerlo de
manera eficiente, es necesario realizar algunas acciones o convenciones.
Además de los patrones orientados a conseguir un software de mejor calidad, también existen
patrones de diseño para maximizar el uso de nuestra aplicación. Por ejemplo, En Android se
recomienda hacer que las navegaciones mediante pestañas se sitúen en la parte superior de la
pantalla, mientras que en iOs se recomienda que estén en la parte inferior.

Patrones de diseño de la UI (interfaz de usuario)
Cuadro de control (dashboard)
Problema: Acceder de manera rápida, clara y sencilla a las funcionalidades principales de

la aplicación. En el caso del móvil, es importante por la responsabilidad que el usuario
requiere.
Solución: Tener una página de llegada con la información clara de la última información de
la aplicación y las acciones más importantes.
Resaltar lo que es nuevo.

Enfocar de tres a seis características importantes.

Barra de acción (action bar)

Problema: La limitación de espacio de las pantallas
hace pueda ser muy complicado mostrar las acciones
que el usuario puede hacer en una pantalla, y puede
provocar mucha pérdida de espacio útil si se introduce
un objeto visual botón por cada acción.
Solución: Se agrupan todas las acciones que se pueden

hacer en la pantalla actual en una zona, en la parte
superior o inferior (dependiendo de la plataforma), para
aprovechar mejor el espacio y tener una mayor cohesión
entre aplicaciones. Además, se puede aprovechar este
espacio para indicar el lugar de navegación donde nos
encontramos.

Menús contextuales (quick action menu)

Problema: Las limitaciones de espacio para las acciones
propias de un elemento de la pantalla ocuparían,
potencialmente, mucho espacio.
Solución: Se muestra un menú contextual al pulsar el

objeto, generalmente en la imagen (por ejemplo, en las
imágenes de los contactos), y así se evita tener que añadir
más ruido a la interfaz. Dentro de este menú se pueden
agrupar todas las acciones correspondientes al objeto en
cuestión.
Se recomienda:

Usarlo solo para las acciones más obvias e
importantes

Usarlo cuando el objeto no tenga una vista
especialmente diseñada para él. En ese caso,
hay que ir a esa vista y mostrar allí la
información.

No usar en contextos donde se soporten
múltiples selecciones.

Lista dinámica (dynamic list)

Problema: Cargar muchos datos en una lista puede ser muy lento, especialmente si hay
problemas de red. Para el usuario puede suponer una mala experiencia si tiene que
esperar a que se cargue toda una lista (que en ocasiones no acaba o es muy grande).
Solución: En lugar de esperar a que la lista se cargue, se pueden mostrar los datos
relevantes y cargar la lista inmediatamente. Los datos que faltan se pueden cargar cuando
el usuario lo pida, o bien cuando la aplicación prevea que va a ser así (por ejemplo,
cuando se desplace hacía el final de la lista).

Mensajes de alerta
Problema: Sucede un evento en el sistema o la aplicación que

es relevante para el usuario.
Solución: Mostrar un mensaje de alerta, que llama la atención

del usuario, para advertirle de la situación. Por ejemplo, cuando
hay problemas de batería o cuando nuestra aplicación ha
detectado una perdida de conexión.
Se recomienda:

Usarlo solo para mensajes importantes y necesarios. Este tipo de mensajes son
muy invasivos, y el usuario, en lugar de sentirse agradecido por recibirlos, puede
acabar ignorándolos.

Realizar alguna acción cuando sea necesario; mostrar una de las opciones como
atajo para dicha acción. Por ejemplo, si hay un problema de espacio en el disco,
una de las acciones irá al gestor de aplicaciones instaladas para eliminar las que
no necesitemos.

Desarrollo con Entornos
Multiplataforma
TITANIUM
PHONEGAP
IONIC
RHODES 44
IONIC

IONIC (Aplicaciones híbridas)

El MVC
(Model-View-Controller o Modelo-Vista Controlador)
1.- Modelo
Es la capa encargada de los datos, es decir, la que se encarga de hacer peticiones a
las bases de datos para enviar o recibir información. Estas bases de datos pueden
estar alojadas de forma local en nuestra app o de forma remota en un servidor
externo.
2.- Vista
Se trata del código que nos permitirá presentar los datos que el modelo nos
proporciona, como ejemplo podríamos decir que en una aplicación es el código HTML
que nos permite mostrar la salida de los datos procesados.
3.- Controlador
Es la capa que sirve de enlace entre la vista y el modelo. Envía comandos al modelo
para actualizar su estado, y a la vista correspondiente para cambiar su presentación.
En el caso MVVM (Modelo Vista VistaModelo) la iteracción entre la vista y el

controlador será en los dos sentidos, el controlador muestra los datos en la vista y si
en la vista hay un cambio de datos, se actualiza el modelo automáticamente

IONIC (Arquitectura)
En ionic como en cualquier modelo vista - controlador las diferentes secciones de la

intefaz se pueden dividir en distintas vistas hijas o incluso podrían ser vistas hijas que
contengan a su vez otras vistas hijas.
Los controladores están asociados a estas vistas y se encargan de proporcionar los datos
necesarios y la funcionalidad de los diferentes elementos.
Los controladores: obtienen los datos de uno o varios

Servicios o Factorías y lo envían a una vista o template a
través de la variable $scope.
Las vistas o templates contienen la descripción visual

de una pantalla (o de una parte de una pantalla) y obtienen
los datos a mostrar de la variable $scope.
La configuración y las rutas de la aplicación permiten

enlazar los controladores con las vistas o
templates correspondientes.
Las directivas permiten crear y usar componentes con

aspecto y comportamiento personalizado.

IONIC (Instalación)
1- NodeJs (https://nodejs.org/en/)
$ sudo apt-get install nodejs
$ sudo apt-get install npm
2- IONIC
$ sudo npm install -g cordova ionic
3- Otras dependencias:
$ sudo npm install -g gulp Gulp (http://gulpjs.com/) es un sistema de construcción que

$ sudo npm install -g bower permite automatizar tareas comunes o repetitivas de desarrollo,
tales como la minificación de código JavaScript, recarga del
$ sudo gem install sass navegador, compresión de imágenes, validación de sintaxis de
. código y un sin fin de tareas más. Para mas información
consultad:
Bower (http://bower.io/) es un gestor de paquetes para el

desarrollo Web.
SASS (http://sass-lang.com/) es un metalenguaje de CSS que

nos permite programar hojas de estilo usando variables, reglas
CSS anidadas, mixins, importación de hojas de estilos , etc.

IONIC (Crear un proyecto)
1- Definir un nuevo proyecto
Ionic permite la creación de proyectos usando su intérprete de línea de comandos (cli).
Tres tipos de proyectos pueden ser creados:
$ ionic start myApp blank

$ ionic start myApp tabs
$ ionic start myApp sidemenu

2- Añadir las plataformas destino
Comando genérico:
$ ionic platform add <nombre-de-la-plataforma>
$ ionic platform add android

Compilar y ejecutar el proyecto.
1- Desde un navegador:
$ ionic serve
Podemos añadir en ambos casos la opción --
2- Desde un emulador consolelogs or -c para ver en el terminal la información
que imprime por consola la aplicación.
$ ionic emulate <PLATFORM>
$ ionic emulate android Si no queremos ejecutar el proyecto y solamente
queremos compilarlo y generar el código destino de la
plataforma podemos usar la opción build indicando
3- Desde un dispositivo real también la plataforma de compilación:
$ ionic run <PLATFORM> $ ionic build <PLATFORM>

$ ionic run -l ios

Estructura de un proyecto
hooks/ - Esta carpeta se utiliza para añadir scripts que se ejecutarán cuando se produzcan determinados eventos, como por ejemplo
antes o después, de la compilación, etc. En la propia carpeta se incluye un fichero con instrucciones para su utilización.
platforms/ - Contiene el código específico de las plataformas móviles para las cuales se va a compilar, como por ejemplo Android,
iOS, etc. El código de esta carpeta es generado y no se ha de modificar manualmente.
plugins/ - Contiene los plugins o módulos instalados para nuestra aplicación, los cuales se utilizan para añadir funcionalidad como el
acceso a las características nativas del móvil.
resources/ - Recursos específicos de las plataformas. En esta carpeta podremos colocar aquellos assets que sean únicos o
dependientes de una plataforma en concreto.
scss/ - Código SCSS que será compilado a la carpeta www/css/
www/ - Contiene el código fuente principal de nuestra aplicación web: HTML, CSS, JavaScript, imágenes, etc. Esta carpeta es donde
tendremos que desarrollar la aplicación web de forma centralizada y después utilizarla para la compilación para las distintas
plataformas.
bower.json - Listado de dependencias y paquetes de Bower.

config.xml - Contiene la configuración de Cordova (o PhoneGap) con las opciones especificas para cada plataformas de
compilación.
gulpfile.js - Listado de tareas de Gulp.
ionic.project - Configuración del proyecto de Ionic.
package.json - Dependencias y paquetes de NodeJS.
css/ - Aquí colocaremos todas las hojas de estilo que se usen en la aplicación.
img/ - En esta carpeta almacenaremos las imágenes de nuestro proyecto.
js/ - Contendrá todo el código JavaScript de la aplicación.
lib/ - Aquí guardaremos todas las librerías que se usen en nuestro código. Por defecto ya viene incluido todo el código de la librería
Ionic (Javascipts, CSS, etc.) para que lo podamos cargar desde nuestro proyecto.
templates/ - Esta carpeta viene preparada para almacenar las plantillas o vistas de la aplicación (en algunas versiones no se crea
por defecto).
index.html - Este es el fichero principal que se abrirá al cargar la aplicación. Aquí tendremos que cargar todo lo necesario y mostrar
el contenido de la primera pantalla.

IONIC (Código básico)
Primero carga la hoja de estilo de Ionic, la cual aplicará los estilos visuales a los
componentes
se incluye por defecto vacía para que escribamos en ella nuestros estilos CSS personalizados
Librería JavaScript de Ionic y

AngularJS
API JavaScript de
Cordova.
En este fichero se inicializa el módulo de Angular que gestionará la

aplicación
A continuación en el body se define la aplicación de AngularJS a utilizar (ng-app="starter"). Este código
asigna el módulo que hemos definido en app.js llamado starter para que gestione el contenido de la página.
En Ionic, la forma de incluir componentes es mediante el uso de clases CSS sobre etiquetas HTML o
mediante el uso de directivas de AngularJS (permiten definir bloques de código HTML con estilos y
funcionalidad asociada). En este caso se utilizan las directivas ion-pane, ion-header-bar y ion-content.

IONIC (Componentes)
Los principales componentes que podemos utilizar son:

 Área de contenidos
 Cabeceras
 Pie de página
 Botones y enlaces
 Listados
 Tarjetas
 Formularios http://ionicframework.com/docs/components/
 Tabs o fichas
 Grid o rejillas
 Y algunas utilidades más
Mediante estos componentes podemos crear una aplicación estática completamente

funcional, que tenga por ejemplo una pantalla con varias fichas, una cabecera y pie de
página, y un listado de elementos, y todo esto escribiendo únicamente código HTML.

IONIC (Inicializando la aplicación)
El punto de inicio de una aplicación Ionic es el fichero index.html, como mínimo debe
contener:
En la cabecera se cargan las dependencias de la aplicación: hojas de

estilo, librería JavaScript de Ionic (la cual incorpora Angular), librería de
Cordova y los ficheros JavaScript de nuestra aplicación (ja/app.js).
En el body se indica el módulo de Angular a utilizar con ng-app="starter".

Esta línea inicia la carga del módulo llamado starter que estará definido en
el fichero js/app.js de la forma: angular.module('starter', ['ionic'])
Un módulo angular se crea de la siguiente forma: como primer parámetro

se indica el nombre del módulo (starter) y a continuación las dependecias,
que en este caso solo se carga la librería de ionic. A continuación
podremos indicar la configuración, los controladores y servicios que
componen el módulo de la forma:

IONIC (Configuración)
La configuración establece las rutas o estados (states) que va a tener la aplicación y

enlaza cada uno de ellos con una ruta, un controlador y un template (la vista). Además se
tendrá que especificar también una ruta inicial o por defecto.
En este ejemplo se establecen dos rutas o estados. La primera

llamada home, que tendrá la URL vacía y usará
el template home.html y el controlador homeCtrl.
La segunda ruta llamada page que tendrá la URL /page, usará

el template page.html y el controlador pageCtrl.
Se establece que por defecto (en la primera llamada y cuando la ruta

no exista) se usará la ruta vacía, que se corresponde con el
estado home.
Funcionamiento:
Al realizar una consulta a la aplicación en primer lugar se creará el

módulo con esta configuración y a continuación se cargará la ruta
solicitada o la ruta por defecto.
Si por ejemplo se solicita el estado home se llamará al controlador

indicado para preparar los datos y a continuación se cargará el
template home.html, se sustituirán los valores de la plantilla con los
indicados en el controlador y por último se mostrará la vista al usuario.
Nota: Si decimos que incluya una plantilla que no existe o nos equivocamos en el nombre del fichero html no mostrará ningún error,
simplemente no funcionará

IONIC (Configuración. Enlaces)
Para crear un enlace que nos lleve a un estado indicado en la configuración simplemente
tenemos que usar el atributo ui-sref con el nombre del estado deseado.
Por ejemplo, para volver al home seria:
<a ui-sref="home">Volver al inicio</a>
Cuidado: Si ponemos un enlace a una dirección que no existe o a un state que no existe
no mostrará un error. Al pulsar intentará cambiar de pantalla pero volverá a mostrarse la
misma donde estaba.

IONIC (Configuración. Rutas con parámetros)
Las rutas con parámetros permiten pasar valores entre vistas.

Por ejemplo, podemos tener un listado de usuarios y al pulsar sobre un elemento de la
lista abrir una nueva pantalla con la vista detalle del usuario.
Es necesario que el enlace indique el índice del elemento pulsado para así poder abrir la
vista con los datos del usuario correspondiente.
Para añadir parámetros a las rutas simplemente los indicarlos añadiendo (:) al nombre del
parámetro en la url, por ejemplo:
En este ejemplo se definen tres rutas o estados. La primera
(users) no tiene ningún parámetro y la usaremos para
mostrar toda la lista de usuarios. La segunda (userDetail)
recibe un parámetro (userId) a partir del cual podremos
obtener los datos del usuario solicitado. Y el último estado
(userPost) recibe dos parámetros para indicar un artículo de
un usuario.
Para generar un enlace a una ruta con parámetros

usaremos también el atributo ui-sref y simplemente tenemos
que añadir al nombre del estado un objeto entre paréntesis
con los valores. A continuación se muestra un ejemplo:
Fuentes de información sobre configuración:

https://github.com/angular-ui/ui-router/wiki
https://github.com/angular-ui/ui-router/wiki/URL-Routing#stateparams-service Nota: Los nombres de las propiedades del objeto tienen que coincidir con los
https://scotch.io/tutorials/3-simple-tips-for-using-ui-router nombres que hayamos puesto a los parámetros de la ruta. Por ejemplo,
en userDetail({ userId: id }), el nombre userId coincide con el de la ruta /user/:userId.

IONIC (Controladores)
Al mostrar una página de la aplicación en primer lugar se llama a un controlador, este

controlador usará una vista (o template) para generar dicha página y además cargará los
datos necesarios medicante servicios (services o factores).
El controlador realiza el envío usando la variable $scope.
Por ejemplo, al acceder a la página #miPagina se llamará automáticamente al controlador

que tendrá como nombre miPaginaCtrl. Este controlador está configurado para usar la
plantilla llamada "superpagina.html con el siguiente contenido:
<ion-view title="About">
<ion-content>
Mi nombre es {{user.name}}.
</ion-content>
</ion-view>

IONIC (Controladores)
Para definir el controlador asociado miPaginaCtrl lo podríamos realizar de la forma:
.controller('miPaginaCtrl', function($scope, $stateParams, superService) {

$scope.user = superService.getUser();
})
Los parámetros que recibe la función del controlador serán inyectados por Angular en la
propia llamada. Podemos usar estos parámetros para cargar servicios o clases que
necesitemos.
En este ejemplo se inyecta la variable $scope que permite pasar datos a la vista, también
se inyecta $stateParams que sirve para recuperar los parámetros de llamada a la ruta o
pantalla actual, y por último se carga superService que es un servicio que se ha creado
para acceder los datos del usuario.
El método getUser() del servicio superService devolverá un
objeto con el siguiente formato:
var user = {
name: "Juan"
}
<ion-content> Al llamar a esta página en primer lugar se ejecutará el controlador
Mi nombre es Juan. asociado, el cual asignará al $scope la variable user con los datos del
</ion-content> usuario. A continuación se procesará la plantilla, la cual accederá a la
</ion-view> variable user.name para obtener el nombre del usuario y sustituirlo.

IONIC (Parámetros)
La clase $stateParams permite recoger el valor de los parámetros de entrada

proporcionados a una ruta. Por lo tanto, en el controlador tenemos que añadir esta clase a
sus argumentos (para que Angular la inyecte) y después simplemente accederemos a los
parámetros como si fueran propiedades de este objeto.
Por ejemplo, si se define en la configuración una ruta para mostrar la vista detalle de un
usuario de esta forma:
.config(function($stateProvider, $urlRouterProvider) {
$stateProvider
.state('userDetail', {
url: '/user/:userId'
});
})
El parámetro userId que recibe esta ruta lo podríamos recoger en el controlador de la forma:
.controller('miSuperPaginaCtrl', function($scope, $stateParams, superService)
{
var userId = $stateParams.userId;
// Usamos userId para obtener los datos del usuario
$scope.user = superService.getUser( userId );
})
!!!CUIDADO!!!
El nombre de variable debe ser el mismo que esté definido, de otra forma obtendríamos el
valor undefined.
Más información se puede encontrar en:
https://docs.angularjs.org/guide/controller
http://mcgivery.com/controllers-ionicangular/

IONIC (Vistas)
Las vistas contienen la descripción de la parte gráfica de una pantalla (código HTML,
CSS, directivas o componentes de Ionic, etc.). Se refieren al concepto de "templates"
según la librería Angular.
Todas las vistas se guardarán dentro de la carpeta "templates/" en diferentes ficheros
con la extensión .html.
Ejemplo de una vista que guardaremos en el fichero /templates/about.html:

<ion-content> Las vistas tienen que ir encerradas dentro de una sección <ion-view> a la
Contenido de la vista que se le puede asignar opcionalmente un título. Este título se utiliza desde
</ion-content> otras directivas como <ion-nav-bar> para obtener el texto de la barra de
título.
</ion-view>
Contenedor o página principal

<!DOCTYPE html>
<html>
<head>
 La directiva <ion-nav-bar>muestra la barra de
</head> navegación e incluye el título indicado en la vista.
<body ng-app="starter">
<ion-nav-bar class="bar-positive"> La directiva ion-nav-back-button permite volver a la
<ion-nav-back-button class="button-clear"> página anterior y solo se mostrará cuando se pueda
<i class="ion-chevron-left padding-left"></i> pulsar.
</ion-nav-back-button>
</ion-nav-bar> La directiva <ion-nav-view> es donde se incluye el
<ion-nav-view></ion-nav-view> contenido de la plantilla de la vista actual.
</body>
</html>

IONIC (Vistas)
Sustitución de variables Bucles
Angular permite crear bucles directamente en la plantilla para repetir un trozo de

Dentro de la vista o plantilla podemos acceder a los datos código mediante el atributo ng-repeat en la etiqueta que queremos que se repita.
proporcionados por el controlador. Para que se muestren debe ser Es importante que la etiqueta se coloque en el mismo atributo a repetir y no fuera.
usado el formato {{nombre_variable}} que se sustituye por el valor de Por ejemplo, para crear una lista el elemento a repetir sería la etiqueta <li>:
dicha variable:
<ul>
<ion-view title="About"> <li ng-repeat="autor in autores">
<ion-content> {{autor.nombre}} {{autor.apellidos}}
Mi nombre es {{name}} </li>
</ion-content> </ul>
</ion-view>
En este código se crea un bucle a partir de la
donde {{name}} es una variable que se ha asignado variable autores, la cual contendrá un array de objetos con
al $scope en el controlador de la forma: los datos de los autores. Esta variable se habrá asignado
a $scope en el controlador correspondiente:
$scope.name = "Juan";
$scope.autores = [
{ nombre: "Juan", apellidos: "García" },
Condiciones { nombre: "Laura", apellidos: "Pérez" }
]
Angular también permite crear condiciones mediante el uso de ng-if/ng-show.
Ambos atributos realizarán la misma acción: mostrar u ocultar el contenido de la etiqueta en la que se encuentren dependiendo de la condición.
Con ng-if la etiqueta se eliminará del DOM si la condición es falsa, mientras que conng-show la etiqueta simplemente se ocultará (pero
permanecerá en el DOM).
Por ejemplo, para mostrar un mensaje si la lista de autores estuviera vacía simplemente tendríamos que hacer:
<div ng-show="!autores.length">
La lista está vacía
</div>
El valor pasado a ng-if/ng-show puede ser una variable, expresión o una función, por ejemplo:
<div ng-show="mostrarAviso()">
Aviso de ejemplo!
</div>
más información:
https://docs.angularjs.org/guide/templates
Y en el controlador podríamos añadir dicho método al $scope simplemente haciendo:
https://docs.angularjs.org/api/ng/directive
$scope.mostrarAviso = function(){ http://mcgivery.com/creating-views-with-ionic/
return false;
}

IONIC (Factories/Services)
La capa de datos en una aplicación Ionic o Angular proporciona los datos desde un
almacenamiento local o externo. Para ello se utilizan unas clases conocidas como
Servicios o Factories.
Los servicios siempre tienen que devolver un objeto (ya que al inyectarlos se les llamará
con new).
Factories son más versátiles y podrán devolver lo que queramos ya que simplemente se
ejecutará la función que lo define.
El controlador solicita los datos a la capa de datos para prepararlos y pasárselos a la
vista. La capa de datos definirá una serie de métodos para el acceso a los datos.
.factory('superService', function() { El servicio superService define un único

return { método getUser() que devolverá un objeto
getUser: function() { con el nombre del usuario.
Siguiendo este esquema podemos añadir
var user = { name: "Juan" }; todos los métodos que queramos al servicio
return user; y definir una API de consulta.
},
} .controller('MiSuperControladorCtrl',
}) function($scope, superService) {
El controlador en primer lugar debe solicitarlo $scope.user = superService.getUser();
en los parámetros para que Angular lo
inyecte. Posteriormente, desde dentro del
})
más información en:
código de la función ya lo podemos usar y https://docs.angularjs.org/api/ng/service/$q
acceder a los valores o funciones que http://mcgivery.com/ionic-using-factories-and-web-services-for-dynamic-data/
hayamos definido en la clase de datos

IONIC (Consultas asíncronas)
En el ejemplo anterior los datos estaban guardados en una variable, pero lo más común es que provengan de un
servicio remoto o desde una base de datos. Si el servicio tarda en devolver los resultados hay que trabajar de
forma asíncrona o la aplicación se bloquea.
Al realizar una petición asíncrona la función del servicio no devuelve el valor directamente, sino que usará la
función. Por ejemplo, para hacer una consulta HTTP a una API externa sería:
.factory('superService', function($http) {
return {
getUser: function() {
return $http.get("url-de-consulta").then(function(response) {
//...
return response;
});
},
} Dentro de la función then podemos procesar los datos obtenidos y después devolver la respuesta.
}) Para usar este servicio desde un controlador lo realizaremos como en el ejemplo anterior: solicitamos
que el servicio se inyecte en los parámetros, llamamos al método de forma normal
awesomeService.getUser() pero la respuesta la tenemos que procesar con la función then. Esta
función se queda esperando a recibir la respuesta y una vez obtenida se ejecutará la función
asignada como primer parámetro:
.controller('MiSuperControladorCtrl', function($scope,
superService) {
awesomeService.getUser().then(function(response){
$scope.user = response;
});
}) Se puede asignar un segundo parámetro a la
función then (otra función callback) que se llamará
más información en:
https://docs.angularjs.org/api/ng/service/$q cuando la petición al servicio o la respuesta fallen.
http://mcgivery.com/ionic-using-factories-and-web-services-for-dynamic-data/

IONIC (Directivas)
Las directivas son marcadores sobre los elementos del DOM (como los atributos, los nombres de elementos o
etiquetas, o las clases CSS) que indican al compilador HTML de Angular ($compile) que asigne un determinado
comportamiento a dicho elemento del DOM o incluso que lo transforme por un bloque completo de contenido.
Las directivas permiten transformar el aspecto y comportamiento del código HTML por otro que definamos
nosotros. En Ionic, todas las etiquetas que empiezan con ion- son directivas de Angular que tienen un
comportamiento y un aspecto asociado. Por ejemplo <ion-list> procesa mediante una directiva de Angular y genera
el código y comportamiento correspondiente a un listado:
IonicModule.directive('ionList', [ '$timeout',
function($timeout) {
return {
restrict: 'E',
require: ['ionList', '^?$ionicScroll'],
controller: '$ionicList',
compile: function($element, $attr) {
//... etc ...
}
}
} La línea restrict: 'E' indica si la directiva se refiere a un atributo, a un elemento o una clase
]); CSS.
La propiedad rectrict puede tener los siguientes valores:
'A' – La directiva se refiere solo a nombres de atributos.

'E' – La directiva se refiere solo a elementos (los nombres de las etiquetas).
'C' – Se refiere al nombre de una clase CSS.
'AEC' – Estas letras se pueden usar de forma combinada para por ejemplo referirnos a la vez
a atributos, elementos y clases.

IONIC (Probemos un ejemplo)
Contenido del fichero index.html

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="initial-scale=1, maximum-scale=1,
user-scalable=no, width=device-width">
<title></title>
<link href="lib/ionic/css/ionic.css" rel="stylesheet">
<link href="css/style.css" rel="stylesheet">
<script src="lib/ionic/js/ionic.bundle.js"></script>
<script src="cordova.js"></script>
<script src="js/app.js"></script>
</head>
<body ng-app="starter">
<ion-nav-bar class="bar-positive">
<ion-nav-back-button class="button-clear">
<i class="ion-chevron-left padding-left"></i>
</ion-nav-back-button>
</ion-nav-bar>
<ion-nav-view></ion-nav-view>
</body>
</html>

Carga todas las dependencias e inicio del módulo starter de Angular.

En el fichero js/app.js se crea el módulo, definiendo las rutas que va a tener:
angular.module('starter', ['ionic'])
.config(function($stateProvider, $urlRouterProvider) {
$stateProvider
.state('home', {
url: '',
templateUrl: 'templates/home.html',
controller: 'homeCtrl'
})
.state('about', {
url: '/about',
templateUrl: 'templates/about.html',
controller: 'aboutCtrl'
});
// Página por defecto

$urlRouterProvider.otherwise('');
})

En la carpeta templates se ubican las plantillas necesarias. En este caso las plantillas
home.html y about.html:
<ion-view title="Inicio">
<ion-content> home.html
Aplicación de ejemplo.
<a ui-sref="about">Información
sobre el autor</a>
</ion-content>
</ion-view>
<ion-view title="Autor">
<ion-content>
El autor de esta aplicación es
{{author.name}}.
about.html </ion-content>
</ion-view>

Definir los controladores y servicios, en este ejemplo también estarán en el fichero

js/app.js. El controlador para el estado home se queda vacío ya que no necesita realizar
ninguna acción.
Controlador del estado home Controlador para el estado about
.controller('homeCtrl', .controller('aboutCtrl',
function($scope) { function($scope, aboutService) {
; $scope.author =
}) aboutService.getAuthor();
})
Servicio aboutService
.factory('aboutService', function() {
return {
getAuthor: function() {
var author = { name: "Juan" };
return author;
},
}
})

Probar la aplicación:
$ ionic start myApp blank
Crear todos lo ficheros necesarios
$ionic serve
$ ionic emulate
$ ionic run

IONIC (Plugins)
Instalar ngCordova
Para instalar:
$ bower install ngCordova o $ sudo bower install ngCordova –allow-root
Se debe incluir "ng-cordova.js" o "ng-cordova.min.js" en el fichero index.html justo antes

de cordova.js y después de incluir AngularJS e Ionic (ya que ngCordova depende de
AngularJS):
<script src="lib/ngCordova/dist/ng-cordova.js"></script>
<script src="cordova.js"></script>
Para usarlo hay que inyectarlo en el módulo como una dependencia de Angular, por
ejemplo:
angular.module('myApp', ['ngCordova'])

IONIC (Plugins)
Uso
Añadir un plugin:
$ ionic plugin add https://github.com/EddyVerbruggen/Toast-PhoneGap-Plugin.git
Ver la lista de plugins instalados:
$ cordova plugin list
Para eliminar usamos plugin remove con el nombre del plugin a eliminar. Este nombre
puede no ser el mismo que el que usamos para instalar, así que lo tenemos que consultar
usando: cordova plugin list.
$ ionic plugin remove nl.x-services.plugins.toast
Puede ocurrir que después de instalar un plugin (ej. sqlite) no se instala todo lo necesario
en la plataforma. En ese caso se debe hacer:
$ ionic platform rm [ios/android] más información en:

$ ionic platform add [ios/android] http://ngcordova.com/docs/plugins/

IONIC (Plugins)
Ejemplo:
Para usar el plugin para trabajar con SQLite:
$ ionic plugin add https://github.com/litehelpers/Cordova-sqlite-storage.git
Ejemplo de su uso desde un controlador:

module.controller('MyCtrl', function($scope, $cordovaSQLite) {
var db = $cordovaSQLite.openDB({ name: "my.db" });
// for opening a background db:

//var db = $cordovaSQLite.openDB({ name: "my.db", bgType: 1 });
$scope.execute = function() {
var query = "INSERT INTO test_table (data, data_num) VALUES (?,?)";
$cordovaSQLite.execute(db, query, ["test", 100]).then(function(res) {
console.log("insertId: " + res.insertId);
}, function (err) {
console.error(err);
});
Más información en:
}; http://ngcordova.com/docs/plugins/sqlite/
});

IONIC (Publicación de la apk)
Para la publicación en el market de aplicaciones los primero es generar la versión release

(o versión final, sin código de depuración) de cada una de las plataformas en la que la
queramos publicar.
Antes de compilar la versión final, revisar los plugins que hemos utilizado durante el
desarrollo. Por ejemplo, por defecto viene incluido el plugin para la mostrar el texto de
depuración por consola, se debe quitar:
$ cordova plugin rm cordova-plugin-console
Para generar la versión release para Android (o cualquier otra plataforma) se debe usar el
siguiente comando:
$ cordova build --release android
Para Android por ejempplo podemos encontrar la apk en

platforms/android/build/outputs/apk.
Más información en:

http://ionicframework.com/docs/guide/publishing.html
http://blog.ionic.io/automating-icons-and-splash-screens/

IONIC (apk de ejemplo)
El siguiente ejemplo muestra el uso de los principales sensores encontrados en los

dispositivos móviles.

IONIC (Documentación y Recursos)
Documentación
Primeros pasos: http://ionicframework.com/getting-started/

Documentación: http://ionicframework.com/docs/
Componentes: http://ionicframework.com/docs/components/
API de Ionic: http://ionicframework.com/docs/api/
Más documentación como vídeos, trucos, foro, etc. en: http://learn.ionicframework.com/
Plugin con multitud de filtros para Angular: https://github.com/a8m/angular-filter
using Ionic to build hybrid applications:
https://www.airpair.com/javascript/posts/a-year-using-ionic-to-build-hybrid-applications
What I learned building an app with Ionic Framework:
http://www.betsmartmedia.com/what-i-learned-building-an-app-with-ionic-framework
5 Ionic Framework App Development Tips and Tricks: http://www.sitepoint.com/5-ionic-app-development-tips-tricks/
Structure of an Ionic App: http://mcgivery.com/structure-of-an-ionic-app/
https://jsjutsu.com/2015/06/21/tutorial-ionic-framework-parte-1/
Recursos para Ionic
Iconos: http://ionicons.com/
Código: http://codecanyon.net/category/mobile/native-web
Previsualización de las Apps: http://view.ionic.io
ngCordova - Versión de Cordova para Angular: http://ngcordova.com
Ionic creator - Crea pantallas básicas de Ionic visualmente: http://creator.ionic.io
Ejemplos de apps hechas con Ionic: http://showcase.ionicframework.com/
Libro sobre Ionic: http://manning.com/wilken/?a_aid=ionicinactionben&a_bid=1f0a0e1d

PHONEGAP

Phonegap (Introducción)
PhoneGap es un framework para el desarrollo de aplicaciones móviles producido por

Nitobi, y comprado posteriormente por Adobe Systems.
PhoneGap permite desarrollar aplicaciones para dispositivos móviles utilizando

herramientas genéricas tales como JavaScript, HTML5 y CSS3.
Las aplicaciones resultantes son híbridas, es decir que no son realmente aplicaciones
nativas al dispositivo (ya que el renderizado se realiza mediante vistas web y no con
interfaces gráficas específicas de cada sistema),
No se tratan tampoco de aplicaciones web (teniendo en cuenta que son aplicaciones

que son empaquetadas para poder ser desplegadas en el dispositivo incluso trabajando
con el API del sistema nativo).

Las aplicaciones PhoneGap no suelen hablar directamente con una base de datos.
Esta comunicación es gestionada a través de una aplicación en el servidor. La

comunicación con el servidor se suele basar en peticiones HTTP estándar para
contenido HTML, como REST-ful, XML, JSON, SOAP o websockets. Serian
exactamente las misma técnicas que son usadas en una aplicación de escritorio
basada en AJAX
La arquitectura de la aplicación cliente suele utilizar un modelo de página única donde

toda la lógica de la aplicación está en una única pagina HTML. Esta pagina permanece
cargada en memoria y los gestiona todo. Los datos se muestran actualizando el DOM
HTML, los datos se guardan desde la aplicación en el servidor a través de técnicas
AJAX y las variables se mantienen en memoria a través de Javascript

Arquitectura

La vista web utilizada por PhoneGap es la misma vista web utilizada por el sistema
operativo nativo.
- En iOS, esta vista será la clase UIWebView de Objective C; en Android será el

componente android.webkit.WebView.Al haber diferencias en los motores de
renderizado web entre sistemas operativos, tendremos que tener en cuenta esto para
el desarrollo (y testeo) de nuestra interfaz.
- PhoneGap proporciona una API que nos permite acceder a las funcionalidades
nativas de los dispositivos móviles utilizando Javascript. Así, podemos desarrollar toda
la lógica de nuestra aplicación en Javascript y utilizar la API de PhoneGap para
acceder a las funcionalidades nativas del dispositivo.

Las aplicaciones PhoneGap son desarrolladas con HTML, CSS y Javascript, sin
embargo, el producto final de una aplicación PhoneGap es un archivo binario (IPA,
APK, XAP…) listo para ser distribuido en los correspondientes marketplaces
Para aplicaciones iOS se genera un archivo IPA (iOS Application Archive), para
Android se genera in archivo APK (Android Package), para Windows Phone se genera
un archivo XAP (Application Package), etc…Estos formatos son los mismo utilizados
por las aplicaciones “nativas” y se pueden distribuir a traves de los canales
correspondientes (iTunes Store, Android Market, Amazon Market, BlackBerry App
World, Windows Phone Marketplace, etc…)

La aplicacion cliente de PhoneGap se comunica con una aplicación en el servidor para

recibir/enviar datos. La aplicación en el servidor gestiona la logica de negocio y se
comunica con la Base de Datos.
El servidor suele ser un servidor web (Apache, IIS, nginx, etc..) que sirve una
aplicación escrita en un lenguaje de servidor como Java, PHP, Ruby, Node.js, etc…
PhoneGap es agnóstico en cuanto a tecnología backend y puede trabajar con
cualquier aplicacion en el servidor que utilice protocolos web estándares. La aplicación
en el servidor implementa la lógica de negocio y los cálculos, y generalmente se
encarga de leer/escribir en la base de datos.

Phonegap
Funcionalidad nativa

Phonegap (Instalación)
El orden a seguir para realizar la instalación en Ubuntu será el siguiente:

1- Oracle Java JDK 8
2- Android SDK
3- Apache ANT
4- NodeJS
5- Cordova o Phonegap
6- Ripple Emulator
7- Un editor de código
1- Oracle Java JDK 8

Para realizar las instalación lo primero que haremos será añadir el repositorio de
WebUpd8 a nuestra lista de repositorios disponibles:
$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update $ sudo apt-get install oracle-

java8-installer
$ java -version $ javac -version

.

2. Descargar e instalar Android SDK
http://developer.android.com/sdk/
Google nos propone descargar Android Studio como
. entorno de desarrollo, pero se puede instalar
únicamente las librerías SDK para compilar, usando la
compilación en consola de Phonegap (CLI).
El último paso será agregar la ruta del SDK al

PATH del usuario
$ gedit .bashrc
export ANDROID_HOME="/home/USER/android-sdk-linux/tools"
export ANDROID_PLATFORM_TOOLS="/home/USER/android-sdk-linux/platform-tools"
export PATH="$PATH :$ANDROID_HOME:$ANDROID_PLATFORM_TOOLS"

Ejecutar en la consola el comando android para comprobar que se abre el SDK

Manager para poder instalar las actualizaciones del SDK que sean necesarias
$ android

3. Instalar Apache ANT
La siguiente herramienta a instalar es Apache ANT, que permite automatizar el proceso

de compilación con Java.
Es una herramienta que Phonegap necesita a la hora de compilar las aplicaciones
para Android, ya que permite ejecutar scripts para generar los archivos .APK
instalables en los dispositivos.
$ sudo apt-get install ant

4. Instalar NodeJS y NPM
NodeJS se puede instalar directamente desde el repositorio, normalmente el desfase

de versiones con respecto al que tenemos para descargar desde su página web no
suele ser demasiado grande. (v10.33 vs 10.35)
NPM, el gestor de paquetes de NodeJS, nos permitirá instalar aplicaciones para
NodeJS desde su repositorio.
$ sudo apt-get install nodejs npm
.
es necesario crear un enlace simbólico al
fichero binario de NodeJS, ya que el instalador
de Ubuntu lo nombra como nodejs, para evitar
ambigüedad con otra aplicación del repositorio
que se llama node.
$ sudo ln -s /usr/bin/nodejs /usr/bin/node

5. Instalar Cordova o Phonegap
$ sudo npm install -g phonegap

.
$ sudo npm install -g cordova

6. Instalar Ripple Emulator
Nos permite hacer debug de nuestra aplicación sobre un navegador sin necesidad de
compilar la aplicación e instalarla en un emulador o un dispositivo.
El emulador Ripple también está disponible como paquete de instalación de NodeJS,

por lo que la instalación la haremos de la misma manera que hemos instalado
Cordova:
$ sudo npm install -g ripple-emulator
.
Se recomienda que la depuración se realice junto con el
navegador Chrome, ya que hay ciertas versiones de
Ripple que pueden producir errores al ejecutarse sobre
Firefox

Creación de un proyecto base Phonegap
Para comprobar la instalación se bebe crear un proyecto base de Phonegap,

observando que no se muestra ningún mensaje de error.
$ cordova create MiProyecto com.pruebas.miproyecto MiProyecto

Phonegap (Creando aplicaciones)
Crear la aplicación
$ cordova create hello com.example.hello HelloWorld
cordova -d permite obtener más información sobre el progreso.
 El primer argumento especifica un directorio “Hola” que se generen para su

proyecto.
 Se creará un subdirectorio www para la página de inicio de su aplicación, junto con

diversos recursos bajo css , js , y img , que seguir común web convenciones de
nomenclatura de archivos de desarrollo.
 El config.xml archivo contiene metadatos importantes necesarios para generar y

distribuir la aplicación.
 Los otros dos argumentos son opcionales: el com.example.hello argumento

proporciona su proyecto con un identificador de dominio y el HelloWorld proporciona
texto en pantalla de la aplicación. Se puede editar tanto de estos valores más adelante
en el archivo config.xml .
.
Añadir plataformas
$ cd hello
$ cordova platform add ios
$ cordova platform add android
$ cordova platform add blackberry10
para comprobar el sistema actual de plataformas:

Añadir
$ cordova platforms ls plataformas
para quitar una plataforma:
$ cordova platform remove blackberry10

$ cordova platform rm android

Construir la aplicación
De forma predeterminada, el cordova create script genera una
aplicación basada en web esquelética cuya portada del proyecto es
$ cordova build el archivo www/index.html. Editar esta aplicación que quieras, pero
$ cordova build ios cualquier inicialización debe especificarse como parte del
controlador de eventos deviceready, que se hace referencia por
defecto a www/js/index.js
En este caso, una vez se ejecuta prepare , puede utilizar como una
$ cordova prepare ios alternativa Xcode SDK de Apple para modificar y compilar el código
$ cordova compile ios específico de plataforma que Córdoba se genera dentro de platforms/ios .
Puede utilizar el mismo enfoque con SDK de otras plataformas.

Añadir características nativas
Para incluir las funcionalidades nativas del dispositivo es necesario añadir plugins que
proporcionan acceso a núcleo de las APIs de Córdoba.
Información básica del dispositivo (dispositivo API):

$ cordova plugin add org.apache.cordova.device
Conexión de red y eventos de batería:

$ cordova plugin add org.apache.cordova.network-information
$ cordova plugin add org.apache.cordova.battery-status
Acelerómetro, brújula y geolocalización:

$ cordova plugin add org.apache.cordova.device-motion
$ cordova plugin add org.apache.cordova.device-orientation
$ cordova plugin add org.apache.cordova.geolocation
Cámara, reproducción multimedia y captura:

$ cordova plugin add org.apache.cordova.camera
$ cordova plugin add org.apache.cordova.media-capture
$ cordova plugin add org.apache.cordova.media

Acceder a archivos en el dispositivo o red (archivo API):

$ cordova plugin add org.apache.cordova.file
$ cordova plugin add org.apache.cordova.file-transfer
Notificación mediante vibración o cuadro de diálogo:

$ cordova plugin add org.apache.cordova.dialogs
$ cordova plugin add org.apache.cordova.vibration
Contactos:
$ cordova plugin add org.apache.cordova.contacts
Globalización:
$ cordova plugin add org.apache.cordova.globalization

SplashScreen:
$ cordova plugin add org.apache.cordova.splashscreen
Abrir nuevas ventanas del navegador (InAppBrowser):

$ cordova plugin add org.apache.cordova.inappbrowser
Añadir
plataformas
Consola de depuración:
$ cordova plugin add org.apache.cordova.console

Uso plugin ls (o plugin list , o plugin por sí mismo) permite los pluguins instalados
actualmente:
$ cordova plugin ls # or 'plugin list'

[ 'org.apache.cordova.console' ]
Para quitar un plugin, referirse a él por el mismo identificador que aparece en el

listado. Por ejemplo:
$ cordova plugin rm org.apache.cordova.console

$ cordova plugin remove org.apache.cordova.console # same

Personalización
El directorio merges permite crear aplicaciones con caracteristicas diferentes

dependiendo de la plataforma. Por ejemplo imaginemos que tenemos que definir un
tamaño específico para los caracteres en android y dejarlo sin especificar para el resto
de plataformas.
1- Editamos el archivo www/index.html y añadimos un enlace a un archivo CSS

adicional, overrides.css :
<link rel="stylesheet" type="text/css" href="css/overrides.css" />
2- Se crea un archivo css vacío www/css/overrides.css, que se aplicaría para todas las
versiones no-Android.
3- Se crea un archivo css overrrides.css dentro del directorio merges/android. En este

css se cambia el tamaño de la letra a 12
body { font-size:14px; }

LA WEB FÍSICA AL SERVICIO DEL
LA WEB FÍSICA
TURISMO GASTRONÓMICO
Gonzalo Cerruela García
Department of Computing and Numerical Analysis
University of Córdoba, E-14071 Córdoba, Spain
Presentación
Introducción
Los dispositivos BLE y la Web Física
Plataforma para la gestión de proyectos
mediante la web física
Caso de Uso: Aplicación al Turismo
Gastronómico
Conclusiones
2
Introducción
➔ Actualmente la Web se compone de más de un billón de sitios con los

que diariamente tenemos que interactuar en la búsqueda de
información mediante navegadores específicos.
➔ Recientemente ha surgido un nuevo concepto denominado Web

física. La idea principal es poder realizar todas las tareas cotidianas
dependiendo de los objetos físicos circundantes (entorno IoT).
➔ La Web física se ha podido convertir en una realidad gracias al

desarrollo de balizas inalámbricas (Beacons) que pueden admitir
protocolos estándares como Bluetooth Low Energy (BLE) y WiFi.
3
Bluetooth 4.0
- Bajo consumo de energía

- Corto tiempo de conexión
y comunicación
- Orientada a mensajes
4
Bluetooth 4.0
5
Bluetooth 4.0
6
Bluetooth 4.0
7
ibeacon
8
ibeacon
9
ibeacon
10
Eddystone specifications
11
Eddystone-UID
12
Eddystone-URL
13
Eddystone-TLM
14
UID vs URL
15
La web Física
16
Plataforma para la gestión de proyectos mediante
la web física
Se distribuyen una serie de dispositivos BLE en un área de interés
(ciudad, recinto ferial, etc.).
Cada uno de estos dispositivos trasmite un servicio genérico, el real
está asignado en la base de datos.
El servidor garantiza una completa personalización de estos servicios y
aplicaciones.
Los servicios con independencia del beacon al que estén asociado
estarán destinados a:
✔ Distribución de contenidos multimedia.
✔ Marketing, prosumer y de redes sociales.
✔ Captación y fidelización de clientes.
✔ Encuestas de satisfacción.
✔ Campañas de promoción.
✔ Conocer las demandas y mejorar las relaciones con el cliente.
17
Plataforma para la gestión de proyectos mediante
la web física
18
Caso de uso:
Una aplicación al turismo gastronómico
Para evaluar el sistema propuesto se implementó un proyecto destinado al turismo
gastronómico, consistente en simular una Feria gastronómica en la que un conjunto de
stands de diferentes empresas/instituciones dan a conocer sus productos, eventos
gastronómicos de la ciudad/entorno y oferta turística-gastronómica.
19
Caso de uso:
Una aplicación al turismo gastronómico
Los turistas/usuarios que se encuentren en una ciudad, pueden interaccionar de forma más
cercana con los productos gastronómicos, las empresas y los objetivos turísticos de la
misma. Entre otras cosas, los usuarios podrán obtener información general y particular de
los productos, los eventos gastronómicos y de las empresas o stands donde se presentan.
Además, podrán realizar la evaluación de los productos, obtener bonificaciones, y compartir
la experiencia en las redes sociales.
20
Conclusiones
Basar la propuesta en la Web física significa poder ir

directamente a la información contextualmente relevante.
Para las empresas interesadas tiene la ventaja de no tener

que invertir en desarrollar aplicaciones específicas
adaptando el modelo general con un enfoque en el
contenido y el cliente.
Desde el punto de vista de la gestión de proyectos software

la Web física permite adaptar aplicaciones ya existentes a
un mayor público con el menor coste posible, facilitado la
actualización de los contenidos.
21
FIN

TODOISM

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TODOISM

Diunggah oleh

Hak Cipta:

Format Tersedia

Tema 1.

Fundamentos, Arquitectura y Desarrollo

Ingeniería de Sistemas Móviles

Ingeniería de Sistemas Móviles 2

[1] Mallick M., (2003), Mobile and Wireless Design

Ingeniería de Sistemas Móviles 3

Ingeniería de Sistemas Móviles 5

Ingeniería de Sistemas Móviles 6

Ingeniería de Sistemas Móviles 7

Para más información visitar: http://www.bluetooth.com

Ingeniería de Sistemas Móviles 8

 La tecnología digital enhanced cordless telecommunicatios (DECT) aparece

Para más información visitar: http://portal.etsi.org/

Ingeniería de Sistemas Móviles 9

 La Infrared Data Association (IrDA) es una asociación que integra más

Ingeniería de Sistemas Móviles 10

Ingeniería de Sistemas Móviles 11

Ingeniería de Sistemas Móviles 12

Ingeniería de Sistemas Móviles 13

Ingeniería de Sistemas Móviles 14

ARQUITECTURA DISPOSITIVO MÓVIL NFC

1. Una bobina o antena incorporada en el

Ingeniería de Sistemas Móviles 15

Ingeniería de Sistemas Móviles 16

 Modo ‘Peer to Peer’ para el intercambio de datos o establecimiento de las

 Modo lector/grabador con capacidad de lectura y escritura de etiquetas o tags.

Ingeniería de Sistemas Móviles 17

Ingeniería de Sistemas Móviles 18

Ingeniería de Sistemas Móviles 19

 Zigbee es un estándar de comunicaciones inalámbricas, regulado por el

Ingeniería de Sistemas Móviles 20

Ingeniería de Sistemas Móviles 21

Ingeniería de Sistemas Móviles 22

Ingeniería de Sistemas Móviles 23

 El high performance radio local area network (HiperLAN) es un

 La primera versión del estándar, HiperLAN1 (HiperLAN Type 1), surgió

 Las WWAN permiten la conexión de redes y usuarios de zonas

Ingeniería de Sistemas Móviles 25

 Pueden utilizar dos tecnologías:

Ingeniería de Sistemas Móviles 26

Ingeniería de Sistemas Móviles 27

GSM. El Group Special Mobile fue el organismo que se encargó de la

Ingeniería de Sistemas Móviles 28

 La generación abarca los sistemas GPRS y EDGE:

Ingeniería de Sistemas Móviles 29

Ingeniería de Sistemas Móviles 30

 HSPA. Es la combinación de tecnologías posteriores y complementarias a

 HSDPA. Es la optimización de la tecnología espectral UMTS/WCDMA,

Ingeniería de Sistemas Móviles 31

 LTE. Es la clave para el despegue de Internet móvil, ya que posibilita la

Ingeniería de Sistemas Móviles 32

Ingeniería de Sistemas Móviles 34

 En general un dispositivo móvil puede definirse con cuatro

Ingeniería de Sistemas Móviles 35

Ingeniería de Sistemas Móviles 36

Los netbooks se consideran a menudo dispositivos móviles debido a su similitud en

Ingeniería de Sistemas Móviles 37

Un dispositivo móvil típico es capaz de acceder a Internet, ya sea mediante

Ingeniería de Sistemas Móviles 38

Ingeniería de Sistemas Móviles 39

Ingeniería de Sistemas Móviles 40

 El concepto de handheld PC es muy antiguo. El diseño puede ser similar al de un

Ingeniería de Sistemas Móviles 41

Ingeniería de Sistemas Móviles 42