diseño de la aplicación móvil “noticias...

Equation Chapter 1 Section 1

Trabajo Fin de Máster

Máster en Organización Industrial y Gestión de

Empresas

Diseño de la aplicación móvil

“Noticias Jurídicas”

Autor: José Luis Olivares Rodríguez

Tutor: José Miguel León Blanco

Dep. Organización Industrial y Gestión de Empresas I

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, Diciembre 2015

1

Trabajo Fin de Máster

Máster en Organización Industrial y Gestión de Empresas

Diseño de la aplicación móvil

“Noticias Jurídicas”

Autor:

José Luis Olivares Rodríguez

Tutor:

José Miguel León Blanco

Dep. Organización Industrial y Gestión de Empresas I

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Índice José Luis Olivares Rodríguez

1

Índice de capítulos

Capítulo 1. Objetivos, estructura del documento y motivación ......................... 5

Capítulo 2. Estado del arte en el diseño de aplicaciones móviles ...................... 7

2.1. Sector y principales problemas del desarrollo de aplicaciones móviles.

Ecosistema, fragmentación y contexto. ........................................................................ 8

2.1.1. Ecosistema de aplicaciones móviles .............................................. 10

2.1.2. Fragmentación ................................................................................ 13

2.1.3. Contexto ......................................................................................... 14

2.1.3.1. Capacidades de los dispositivos .............................................. 15

2.1.3.2. Ubicuidad ................................................................................ 15

2.1.3.3. Contexto social ........................................................................ 16

2.1.3.4. Costes ...................................................................................... 16

2.2. Enfoques de las aplicaciones móviles ................................................... 18

2.2.1. Aplicaciones nativas ...................................................................... 18

2.2.2. Aplicaciones móviles basadas en la Web ...................................... 20

2.2.3. Aplicaciones híbridas ..................................................................... 21

2.2.4. Comparación de los distintos enfoques. ......................................... 22

2.3. Estrategia de desarrollo de aplicaciones móviles.................................. 24

2.3.1. Modelo en cascada ......................................................................... 24

2.3.2. Desarrollo rápido de aplicaciones .................................................. 25

2.3.3. Desarrollo ágil ................................................................................ 25

2.3.4. Mobile-D ........................................................................................ 26

2.3.4.1. Ciclo de desarrollo de Mobile-D ............................................. 26

2.3.5. Diseño centrado en el usuario ........................................................ 26

2.3.5.1. Proceso del DCU ..................................................................... 27

2.3.6. Comparación de los distintos métodos ........................................... 28

Capítulo 3. Diseño de la aplicación Noticias Jurídicas .................................... 29

3.1. Usuarios de la aplicación y contexto .................................................... 30

3.2. Captura de requisitos ............................................................................ 32

3.2.1. Requisitos organizativos ................................................................ 32

3.2.2. Requisitos estratégicos ................................................................... 32

3.2.3. Requisitos del usuario .................................................................... 32

3.3. Producción de la solución. Diseño de la aplicación “Noticias Jurídicas”

33

3.3.1. Solución estratégica ....................................................................... 33

3.3.2. Diagrama de Casos de Uso ............................................................ 33

3.3.3. Diagramas de Actividad de Casos de Uso ..................................... 36


2

3.3.3.1. Ver la página principal de la web “Noticias Jurídicas” .......... 36

3.3.3.2. Navegar a través de las secciones de la web “Noticias Jurídicas”

37

3.3.3.3. Buscar contenido acorde a criterios específicos dentro de la web

“Noticias Jurídicas” ............................................................................................ 38

3.3.3.4. Ver y personalizar las secciones de “Favoritos” de la aplicación

y eliminar noticias de “Favoritos” ...................................................................... 39

3.3.3.5. Añadir noticias a las secciones “Favoritos” de la aplicación .. 40

3.3.3.6. Enviar noticias como enlaces o PDF o extractos de noticias como

texto o PDF. 41

3.3.3.7. Guardar noticias como enlaces ............................................... 42

3.3.3.8. Gestionar las noticias guardadas ............................................. 43

3.3.3.9. Modificar noticas guardadas ................................................... 44

3.3.3.10. Eliminar noticias guardadas .................................................. 45

3.3.3.11. Guardar noticias o extractos de noticias en el dispositivo como

PDF 46

3.3.4. Captura de la experiencia del usuario ............................................ 47

3.3.4.1. Mapa de navegación ................................................................ 47

3.3.5. Modelo de clases de análisis .......................................................... 57

Capítulo 4. Conclusiones y futuras líneas de trabajo ....................................... 60

4.1. Conclusiones del trabajo ....................................................................... 61

4.1.1. Amenazas ....................................................................................... 61

4.1.2. Oportunidades ................................................................................ 61

4.1.3. Debilidades ..................................................................................... 62

4.1.4. Oportunidades ................................................................................ 62

4.1.5. Conclusión ..................................................................................... 62

4.2. Conclusiones del desarrollo del proyecto ............................................. 63

4.3. Futuras líneas de trabajo ....................................................................... 64


3

Índice de tablas

Tabla 1. Relaciones entre sistemas operativos, plataformas, lenguajes de

programación, SDK y dispositivos. Fuentes de fragmentación. .................................... 12

Tabla 2. Matriz DAFO ........................................................................................ 61


4

Índice de ilustraciones

Ilustración 1. Ecosistema de dispositivos móviles. ............................................ 12

Ilustración 2. Proceso del diseño centrado en el usuario (DCU) ........................ 28

Ilustración 3. Diagrama de Casos de Uso ........................................................... 35

Ilustración 4. Ver la página principal de la web “Noticias Jurídicas” ................ 37

Ilustración 5. Navegar a través de las secciones de la web “Noticias Jurídicas” 38

Ilustración 6. Buscar contenido acorde a criterios específicos dentro de la web

“Noticias Jurídicas” ........................................................................................................ 39

Ilustración 7. Ver y personalizar las secciones de “Favoritos” de la aplicación y

eliminar noticias de “Favoritos” ..................................................................................... 40

Ilustración 8. Añadir noticias a las secciones “Favoritos” de la aplicación ....... 41

Ilustración 9. Enviar noticias como enlaces o PDF o extractos de noticias como

texto o PDF ..................................................................................................................... 42

Ilustración 10. Guardar noticias como enlaces ................................................... 43

Ilustración 11. Gestionar las noticias guardadas ................................................. 44

Ilustración 12. Modificar noticias guardadas ...................................................... 44

Ilustración 13. Eliminar noticias guardadas ........................................................ 45

Ilustración 14. Guardar noticias o extractos de noticias en el dispositivo como

PDF ................................................................................................................................. 46

Ilustración 23. Mapa de navegación ................................................................... 49

Ilustración 15. Pantalla "Principal". Ejemplo 1 .................................................. 50

Ilustración 16. Pantalla "Principal". Ejemplo 2 .................................................. 51

Ilustración 17. Pantalla "Secciones". Ejemplo 1................................................. 52

Ilustración 18. Pantalla "Secciones". Ejemplo 2................................................. 53

Ilustración 19. Pantalla "Favoritos" .................................................................... 54

Ilustración 20. Pantalla "Consulta" ..................................................................... 55

Ilustración 21. Formulario “Búsqueda”. Ejemplo 1 ........................................... 56

Ilustración 22. Formulario “Búsqueda”. Ejemplo 2 ........................................... 56

Ilustración 24. Modelo de clases de análisis ....................................................... 59

DISEÑO DE LA APLICACIÓN

MÓVIL “NOTICIAS JURÍDICAS”

Capítulo 1. Objetivos, estructura del

documento y motivación

Capítulo 1. Objetivos, motivación y estructura del documento José Luis Olivares Rodríguez

6

El objetivo de este proyecto fin de máster es el diseño de la aplicación móvil

“Noticias Jurídicas” a partir de la página Web externa “Noticias jurídicas”.

Debido a la envergadura del trabajo, en este proyecto se abarcará todos los

aspectos relevantes al diseño funcional y organizacional de la aplicación, quedando fuera

de él, la implementación, testeo y comercialización. Para ayudar en la consecución de la

solución final y para establecer un proceso de trabajo lógico, el documento está

estructurado de la siguiente manera:

Capítulo 1. Es el capítulo actual, en el que se establecen los objetivos y la

motivación del proyecto y su estructura.

Capítulo 2. Centrado en la parte de investigación del proyecto, en él se presenta

los principales problemas en el desarrollo de aplicaciones móviles, los tipos de

aplicaciones que existen actualmente y las diferentes alternativas más representativas a la

hora de decidir qué estrategia de desarrollo a seguir.

Capítulo 3. En el capítulo 3 es donde se establece cómo va a ser el diseño de la

aplicación y la solución final. A través de los distintos apartados de este capítulo se

establece la solución técnica y estrategia de desarrollo más adecuada para la aplicación,

cuáles son los requisitos que debe satisfacer y cómo va a ser la experiencia y la interfaz

entre el usuario y la aplicación.

Capítulo 4. Aquí se presentan las conclusiones del proyecto y las futuras líneas de

trabajo.

La motivación de elegir este proyecto es debido por un lado, al interés personal

que tengo en el mundo del desarrollo de aplicaciones en general, y, por las posibilidades

que ofrece y el gran auge del sector, las aplicaciones móviles en particular. Y por otro

lado, a que este proyecto servirá como base para estudiar una oportunidad de negocio y

su viabilidad.

La idea del desarrollo de esta aplicación surgió de un usuario de la web “Noticias

Jurídicas” y como resultado de este proyecto se obtendrá una primera aproximación de la

solución profesional.



Capítulo 2. Estado del arte en el diseño

de aplicaciones móviles

Capítulo 2. Estado del arte en el diseño de aplicaciones móviles José Luis Olivares Rodríguez

8

Previo al diseño de la aplicación, es necesario hacer una labor de investigación

para recopilar, analizar y posteriormente tomar decisiones y enfoques para que la solución

final pueda cumplir con los requisitos y conseguir optimizar el proceso para logarlo.

Esta labor de investigación o estado del arte se desarrolla en este capítulo,

abordando tres puntos básicos inherentes al diseño:

Problemas

Enfoque

Estrategia de desarrollo

2.1. Sector y principales problemas del desarrollo de aplicaciones móviles.

Ecosistema, fragmentación y contexto.

Si el desarrollo de cualquier aplicación o servicio lleva asociada una gran

incertidumbre (aceptación del mercado, problemas técnicos no detectados en el primer

análisis, sobrecostes, etc.), en el caso concreto de las aplicaciones móviles, la

incertidumbre y las dificultades son aún más notables.

A los problemas ya existentes en las primeras aplicaciones, tales como la

fragmentación y la calidad de servicio de las redes, hay que sumarle problemas

emergentes como son el acceso a la información del entorno, las diferentes capacidades

de los dispositivos o los distintos sistemas operativos y versiones. Esta problemática hace

que sea muy difícil ofrecer una receta mágica para el desarrollo de aplicaciones móviles.

Si bien, los móviles ya tenían una gran penetración en el mercado y eran usados

como herramienta de trabajo o elemento de la vida diaria, las aplicaciones móviles no han

tenido anteriormente, y hasta ahora, esta aceptación debido principalmente a la ya

mencionada fragmentación (era muy complicado desarrollar aplicaciones ejecutables en

todos los dispositivos) y al coste de desarrollo o de adaptación entre escenarios. Sólo

algunas aplicaciones han sido ampliamente usadas, como es el caso del SMS y el MMS

(Ramírez Vique, 2013).

No ha sido hasta el auge del sector de la telefonía móvil con el boom de los

smartphones y de los dispositivos móviles, hasta cuando el sector de las aplicaciones

móviles ha conseguido despegar e ir de la mano del sector de la telefonía móvil. Ahora el

panorama es completamente distinto, ambos sectores se encuentran en auge en todo el

mundo y especialmente en España y son considerados como los sectores de mayor

innovación y que mayor expectación causa. Concretamente y en términos de cifras de

2014, se observó que (Ditrendia - Digital Marketing Trends, 2015):

El número de teléfonos móviles superó al de personas en el mundo, 7.300

millones vs 7.200.


9

En todo el mundo, se vendieron 1.245 millones de smartphones, lo que

supone un aumento del 28,4 % frente al año anteriores.

Durante 2014 la gente pasó más tiempo navegando en Internet desde el

móvil que tiempo delante de la televisión.

A final de 2014, el número de líneas móviles en España superó los 50,6

millones, un 1,2% más que el año anterior.

En España, los smartphones suponen el 87% del total de móviles.

En España, el 90% de los usuarios de smartphones se conectan a Internet

todos o casi todos los días y el 75% varias veces al día.

El auge del sector, si por un lado ofrece grandes posibilidades de desarrollo para

las aplicaciones móviles, por otro lado genera cumplir unas altas expectativas (fruto del

crecimiento rápido del sector) y conocer todos los actores y factores relevantes del

entorno o ecosistema para no fracasar. A continuación se listan algunos de ellos, pero el

concepto de ecosistema y sus componentes se desarrollan más explícitamente en el

siguiente apartado:

Mejoras constantes en las características hardware de los dispositivos

móviles.

Diversidad en plataformas y dispositivos y su ritmo de innovación.

Especialmente relevantes iOS (iPhone, iTocuh y iPad) y Android.

La penetración de mercado de los dispositivos móviles, que forman parte

de la vida cotidiana de muchos usuarios.

El fácil acceso a tarifas de Internet móvil y su precio y los numerosos

puntos de conexión Wi-Fi (en el hogar, trabajo, transportes públicos,

aeropuertos, instituciones públicas, restaurantes, etc.).

La disponibilidad a diario de nuevas aplicaciones en las tiendas de

aplicaciones o en servidores Web, desarrolladas tanto por aficionados

como por profesionales o grandes empresas.

La fácil monetización o facilidad de venta de las aplicaciones.

El uso generalizado de las redes sociales, que pueden ser la base del

desarrollo de una aplicación o ser un complemento ideal.


10

2.1.1. Ecosistema de aplicaciones móviles

El ecosistema móvil lo componen el conjunto de actores y medios necesarios que

hacen posible la disponibilidad tanto de los dispositivos móviles como de las aplicaciones

para ellos. Antes de empezar con el desarrollo de cualquier aplicación es preciso

conocerlos, ya que en una primera idea se puede obviar muchas restricciones o futuras

complicaciones. El ecosistema móvil lo componen las operadoras de telefonía, las redes

de comunicación, los dispositivos, las plataformas, los sistemas operativos, los entornos

de aplicaciones, las aplicaciones y los servicios (Fling, 2009).

Operadoras de telefonía. Se encargan de que el ecosistema móvil funcione. Son

responsables tanto de tareas tradicionales (instalar y operar torres de comunicación y

hacer que servicios como Internet estén disponibles), como de tareas más innovadoras

que son consecuencia del desarrollo del sector (gestionar servicios de pago entre usuarios

y empresas ofertantes, establecer relaciones comerciales con los suministradores de

dispositivos y ofrecer nuevos servicios que no les competen). Las más importantes en

España son Telefónica, Vodafone y Orange, concentrando el 90% de las líneas móviles

(El País, 2015).

Redes de comunicación. Operadas por las operadoras, son las tecnologías Wireless

que se utilizan para transmitir señales desde las antenas de las torres de comunicación

hasta los distintos dispositivos receptores (pc, televisión, móvil, etc). Entre estas

tecnologías se encuentran redes 2G, 3G, 4G, Wi-Fi, WiMAX, etc.

Dispositivos. A grandes rasgos hay dos grupos de dispositivos, los dispositivos de

gama media y los smartphones (considerando las tablets como portátiles limitados). El

uso de dispositivos de gama media está centrado sobre todo en economías emergentes y

en desarrollo y constituyen el 30% del total, mientras que los smartphones tienen un uso

más extendido en Estados Unidos y la Unión Europea, constituyendo el 70% del total

restante (Ditrendia - Digital Marketing Trends, 2015).

Plataformas. Son las encargadas de proveer de acceso a los dispositivos. Es la

herramienta a través de la cual se puede ejecutar código y servicios en cada uno de estos

dispositivos. Cada plataforma tiene su propia interfaz y experiencia de usuario, lenguaje

de programación, API/SDK y soporte (Erfani, Ali Mesbah, & Kruchten, 2013). Se

diferencian en tres categorías: licencias, propietarias y código abierto.

Licencias. Las plataformas son vendidas a los suministradores de

dispositivos para una distribución no exclusiva. El objetivo es crear una

plataforma de desarrollo común que se pueda trabajar de forma similar a

través de múltiples dispositivos con el menor esfuerzo de adaptación

posible entre dispositivos. Entre las licencias, se puede encontrar Java ME,

BREW, Windows Mobile y LiMo.

Propietarias. Las plataformas propietarias son diseñadas y desarrolladas

por los suministradores de dispositivos para su uso en sus propios

dispositivos. Cabe destacar las plataformas iPhone, BlackBerry y Palm.


11

Código abierto. Son plataformas con código disponible para usuarios que

las quieran descargar, cambiar o editar. Son gratuitas, y Android es la más

destacable de entre estas plataformas.

Sistemas operativos. Contienen las herramientas o servicios que hacen posible que

las aplicaciones sean capaces de comunicarse entre ellas y compartir datos o servicios.

Los sistemas operativos más comunes son Android, iOS y Windows Mobile y en lo que

a cuota de mercado se refiere, Android es el sistema operativo más extendido en el

mercado con un 76,6%, siguiéndole de lejos iOS con un 19,7%. La cuota para el resto de

sistemas es casi despreciable (Ditrendia - Digital Marketing Trends, 2015).

Entornos de aplicaciones. Lo componen los SDK (kit de desarrollo de software)

y las API (interfaz de programación para aplicaciones). De todos los actores o medios

descritos hasta ahora, este es el primero sobre el que los desarrolladores pueden decidir.

Los entornos de aplicación se ejecutan sobre los sistemas operativos, compartiendo

servicios tales como comunicaciones, mensajería, gráficos, localización, seguridad,

autentificación y muchos otros. Existen numerosos entornos de aplicación disponibles en

el sector como son Java, S60, Flash Lite, Windows Mobile, Cocoa Touch, Android SDK,

iOS SDK, Web Runtimes, WebKit y la Web.

Aplicaciones. El gran reto en el desarrollo de una aplicación móvil es conocer los

atributos y las capacidades del dispositivo concreto en el que se va a utilizar. Conocer la

versión de la plataforma que el dispositivo puede soportar, las dimensiones de la pantalla,

el procesador, las capacidades gráficas, el número de botones que tiene y su orientación,

los métodos de entrada de información, los propios usuarios y su interacción con la

aplicación, los canales de distribución de la aplicación, etc.

Las aplicaciones se han convertido en el medio preferido por los usuarios prefieren

trabajar con aplicaciones antes que con sitios Web, un 74% vs a un 64% (Nielsen, 2013).

Casi el 90% del tiempo los usuarios se conectan en sus móviles a partir de aplicaciones,

se lanzan 40.000 nuevas aplicaciones cada día y Google Play e iOS cuentan en 2014 con

más de 2,5 millones de aplicaciones (Ditrendia - Digital Marketing Trends, 2015).

Servicios. Tales como acceso a Internet, enviar un mensaje de texto, obtener una

localización, etc., básicamente, todo lo que el usuario intenta hacer con el dispositivo. Los

servicios se traducen en soluciones a pequeñas tareas que el usuario quiere ejecutar, tales

como “Quiero acceder a la Web”, “Quiero acceder a Google”, “Quiero enviar un mensaje

de texto”.


12

Sistema

Operativo Plataformas

Lenguajes de

progamación

SDK (más

usado)

Dispositivos

(ejemplos)

Android Android Java, C, C++ Android SDK Motorola Moto G,

…

iOS iPhone Objective-C, C,

C++ Xcode iPhone, iPad, …

Windows

Phone

Windows

Phone C#, VB.NET, etc.

Visual Studio,

Windows Phone Meizu MX4, …

Blackberry

OS Blackberry Java

BB Java Eclipse

Plug-in

Blackberry Q10,

Blackberry Z10, …

Tabla 1. Relaciones entre sistemas operativos, plataformas, lenguajes de programación, SDK y dispositivos.

Fuentes de fragmentación.

Ilustración 1. Ecosistema de dispositivos móviles.

Servicios

Aplicaciones

Entornos de aplicaciones

Plataformas

Sistemas operativos

Dispositivos

Redes de comunicación

Operadoras de telefonía


13

Como conclusión de este ecosistema, cabe destacar que es mucho más

heterogéneo que el resto de desarrollos de software:

Los dispositivos móviles suelen estar conectados a Internet mediante una

conexión (ya sea Internet móvil o Wi-Fi) que se contrata y gestiona con

una operadora.

Las operadoras pueden limitar la funcionalidad, accesibilidad y

disponibilidad de los dispositivos (ofrecen grandes descuentos en la

adquisición de dispositivos a cambio de la exclusividad de funcionamiento

en sus redes y pueden influir en la entrada al mercado de nuevos

dispositivos y salida de los disponibles).

Las aplicaciones pueden ejecutarse en diferentes tipos de dispositivos (ya

sean móviles de gama media, smartphones, tablets PC, o incluso

dispositivos menos evidentes como una Smart TV o una Smart card) y en

distintos sistemas operativos y plataformas (con sus entornos de aplicación

asociados).

Si bien el ecosistema móvil puede causar una gran fragmentación, y que para que

el correcto funcionamiento de la aplicación se deba tener en cuenta numerosos factores,

también ofrece la gran ventaja de poder obtener información útil sobre el entorno dónde

se ejecuta las aplicaciones. Este es uno de los puntos fuertes o claves de los dispositivos

móviles frente a los dispositivos fijos y que una aplicación puede utilizar para mejorar la

experiencia del usuario. Un ejemplo de la información que se podría obtener del

ecosistema sería:

Información de la red de comunicación. Información del lugar dónde se

encuentra la conexión.

Información del propio dispositivo. Posición geográfica.

Información sobre otros dispositivos. Localizar dispositivos en

movimiento.

Información sobre el usuario. Contactos, calendario, eventos, redes

sociales, compras, etc.

2.1.2. Fragmentación

Considerando un ecosistema como un escenario, se denomina fragmentación al

impedimento de que una misma aplicación sea capaz de ejecutarse en distintos escenarios.

Dicho de otra forma, son las condiciones particulares de un escenario que hacen que la

aplicación no se pueda compartir con otros escenarios.


14

Como se ha visto en la presentación del ecosistema móvil, son muchos los factores

que son fuentes de fragmentación y que pueden provocar importantes consecuencias

durante el desarrollo de la aplicación. A niveles de gestión (y sin entrar en el detalle

técnico) se podría decir que la fragmentación puede afectar a:

La calidad del producto. Se reduce debido a la necesidad de adaptar la

aplicación a más de un escenario, haciendo el código más complejo (se

incrementan los errores y el mantenimiento).

Número de dispositivos soportados. Son menores los dispositivos para los

que la aplicación estará disponible (usuarios).

La planificación del proyecto. A los imprevistos derivados de la ejecución

de un proyecto “normal”, se añade los problemas derivados de la

adaptación entre escenarios (más crítico incluso si la adaptación a un

escenario conlleva el desarrollo de un proyecto en sí mismo).

Costes asociados. Costes derivados de la calidad (corrección de errores,

mantenimiento, actualizaciones), del número de dispositivos soportados

(mayor inversión en implantación y testeo) y de la planificación (la

dilatación del proyecto y la repetición de fases entre escenarios).

Sin duda, la fragmentación ha sido, y seguramente será, la mayor dificultad y el

mayor riesgo en el desarrollo de aplicaciones móviles (Ramírez Vique, 2013) y las

estrategias para combatir la fragmentación dependerá del grado de la misma. Es decir, si

la fragmentación se produce entre dispositivos (Smartphone y tablets pc), entre

plataformas (Android e iPhone) o versiones de la misma plataforma, entre sistemas

operativos (Windows Mobile y Android), etc.; y vendrá dada por el enfoque de la

aplicación.

2.1.3. Contexto

La gran ventaja que representa el desarrollo de aplicaciones móviles frente a otros

softwares es la posibilidad de obtener información del entorno. Es sin lugar a dudas, un

factor diferenciador y que puede constituir un valor diferenciador respecto a aplicaciones

más tradicionales. Las nuevas capacidades de los nuevos dispositivos y la posibilidad de

conocer información sobre el usuario del dispositivo y sobre el entorno y momento en el

que se ejecuta la aplicación, forman este valor diferenciador. Un ejemplo, es la aplicación

Google Map que puede utilizar la posición geográfica del dispositivo para establecer rutas

de destino desde la posición del usuario, eliminando la dependencia de mapas físicos u

ofrece la posibilidad de calcular nuevas rutas si el usuario se encuentra perdido.

Se podría definir el contexto como el conjunto de todas las informaciones

presentes al mismo tiempo en un momento determinado, pudiendo ser estas

informaciones del dispositivo, de otras aplicaciones, de la situación concreta del instante

de tiempo o del usuario.


15

2.1.3.1. Capacidades de los dispositivos

Son muchos los nuevos factores que hacen que un dispositivo sea capaz de

obtener información del entorno en el que se ejecuta una aplicación y es lo que ha

supuesto el gran avance respecto a los móviles de gama media o tradicionales.

Actualmente, se han desarrollado y se siguen desarrollando numerosas funciones

nuevas que pueden aportar y conseguir información del entorno.

En los nuevos dispositivos se han incorporado funcionalidades y APIs que

permiten conocer la orientación del dispositivo, tomar una foto, conocer la

presión, grabar vídeos y audio, el uso como linterna, escuchar la radio, conectarse

con otros dispositivos, obtener información sólo accesible con dispositivos

portátiles (códigos QR), etc. Estas funciones desarrolladas no sólo afecta a los

dispositivos, sino que se pueden dar en cualquier actor o medio del entorno.

Un gran ejemplo son las mejoras en las redes de comunicación, en donde

la inversión y la innovación en tecnologías Wireless han hecho posibles la

aparición de redes 3G y 4G (recientemente), mejoras en la comunicación

Bluetooth, nuevos estándares WIFI o nuevos protocolos de comunicación (como

es el caso de NFC, que permitirá pagos con el móvil y comunicar información del

entorno).

2.1.3.2. Ubicuidad

Se puede definir la ubicuidad como la capacidad de satisfacer las

necesidades de información o el acceso a determinados servicios de un usuario en

cualquier momento y circunstancia a través del dispositivo.

El grado de ubicuidad de los dispositivos móviles (con aplicaciones

instaladas en ellos) es muy alto debido a que casi todos los usuarios los llevan

consigo como accesorio diario tanto en el ámbito profesional como en el personal.

La gestión de la información personal del usuario a través de aplicaciones móviles

(aplicaciones de tareas, calendario, etc), el fácil acceso a Internet, que hace posible

obtener información útil para el usuario en tiempo real (notificaciones de correo,

de mensajería instantánea, de búsquedas de empleo, etc.) y el uso más práctico

frente a dispositivos fijos son los tres principales factores que hacen que la

ubicuidad sea casi total en aplicaciones móviles.

Considerando la ubiquidad como un medio de comunicación para acceder

y establecer una relación con el usuario, son numerosos las ventajas que presenta

frente a otros medios y que hacen los dispositivos y las aplicaciones móviles más

competitivas:

Es un medio de comunicación que siempre acompaña al usuario.


16

Al acompañar al usuario, el usuario tiene acceso al medio de

comunicación constantemente.

Con el auge del sector, hay muchísimos usuarios con dispositivos

móviles (smartphones principalmente).

Los dispositivos pueden estar permanentemente encendidos,

captando información a través de las aplicaciones (notificaciones y

alertas, por ejemplo) mientras que el usuario no lo está usando.

Cada vez existen más funciones y aplicaciones para el usuario que

le permiten una mayor operatividad (compras, sistemas de pago,

transferencias bancarias, etc.)

2.1.3.3. Contexto social

El gran crecimiento de las redes sociales sumado a la capacidad de

ubicuidad de las aplicaciones hace que el contexto social sea un factor clave para

la aceptación y uso de la aplicación por los usuarios. El uso de redes sociales se

encuentra en continuo crecimiento y penetración en Internet; la posibilidad de

intercambiar fotos con amigos o familiares, seguir a gente influyente o empresas,

básicamente interactuar y conectar con otros usuarios (conocidos o desconocidos)

puede potenciar drásticamente el uso de la aplicación.

Incluso hay casos, como Android, en donde para sacarle el mayor partido

a nuestro dispositivo es necesario acceder con unas credenciales de Google y su

capa social, permitiendo automáticamente conectar con todos los amigos del

usuario de dicho servicio y permitiendo obtener el máximo partido a muchas

aplicaciones (Ramírez Vique, 2013).

2.1.3.4. Costes

La gran desventaja de la contextualización son los costes asociados, que

no necesariamente tienen que estar relacionados con el coste monetario. Algunos

de estos costes afectan al consumo y la vida de la batería, la vulneración de la

privacidad y las necesidades de hardware y de inversión por fragmentación (coste

monetario).

Limitación del consumo y de la vida de las baterías. A día de hoy, todavía

se necesita una gran inversión en el desarrollo de baterías para dispositivos

móviles que sean capaces de elevar la autonomía más de 24-48 horas con un uso

continuado de aplicaciones (Whatsapp, Gmail, Linkedin, Google Map, etc.). A la

hora de desarrollar una aplicación se ha de tener en cuenta este factor, ya que

puede afectar mucho al rendimiento tanto de la aplicación como del dispositivo.


17

Vulneración de la privacidad. Este es uno de los factores que no se tiene

en cuenta en el primer diseño de la aplicación y que tiene una importancia vital.

Para poder explotar todas las posibilidades que nos ofrece el contexto, es necesario

acceder a información del usuario. Cualquier acceso a esta información tiene que

tener el explícito permiso del usuario (por lo que si se necesita este tipo de

información, la aplicación a desarrollar tiene que pedir el permiso de acceso) y

contemplar la posibilidad de revocarlo.

Necesidades de hardware. Afecta tanto a los dispositivos móviles como a

la infraestructura que ofrece el servicio. Un ejemplo claro es la velocidad de

transmisión de datos, que por un lado dependerá de las capacidades de la tarjeta

de red del dispositivo, y por otra, de la cobertura que ofrece la red de la operadora

de telefonía en el punto de conexión.

Necesidades de inversión por fragmentación. Como se ha hablado ya en

este documento, la aparición de una nueva fuente de fragmentación supone

invertir tiempo y/o dinero en conseguir la disponibilidad de la aplicación en este

escenario. Esta inversión puede suponer no tener que hacer nada o realizar todo

un desarrollo nuevo.


18

2.2. Enfoques de las aplicaciones móviles

Existen tres enfoques a la hora de desarrollar una aplicación móvil, y,

naturalmente, la elección de uno de ellos frente al resto dependerá de los requisitos y las

necesidades que debe satisfacer la aplicación. Estos enfoques son de desarrollo de

aplicaciones nativas, aplicaciones Web o aplicaciones híbridas, y se podría decir que los

grandes factores que intervienen a la hora de decidir el enfoque de la aplicación son el

coste, el número de dispositivos en los que se puede ejecutar la aplicación y la experiencia

del usuario.

2.2.1. Aplicaciones nativas

Las aplicaciones nativas son aquellas que se conectan directamente y sin

intermediarios ni contenedores al sistema operativo del dispositivo y puede acceder

libremente a todas las APIs.

Al igual que un programa para Windows o Linux (o cualquier otro sistema

operativo de PC), estas aplicaciones se instalan en el dispositivo y sólo es necesario

ejecutar la aplicación para ponerla en funcionamiento. Una vez ejecutada, la aplicación

puede acceder sin problemas a todas las APIs del sistema operativo y que en muchos

casos contienen funciones únicas típicas del sistema operativo en cuestión. Para instalar

una aplicación en el dispositivo es suficiente con hacerlo desde el PC (u otro dispositivo

compatible) o descargarla directamente desde las tiendas de aplicaciones, valga el

ejemplo de la App Store de Apple, Marketplace de Android, App World de BlackBerry

o Windows Phone de Windows.

Para poder crear una aplicación nativa, un desarrollador debe escribir, por un lado,

el código fuente del sistema operativo concreto en el que se va a ejecutar la aplicación y,

por otro lado, preparar los archivos que va a utilizar la aplicación (imágenes, audio,

formularios, archivos de texto, etc.), también en formatos que sea capaz de usar el sistema

operativo. Para facilitar la vida del desarrollador y para extender el uso de los sistemas

operativos nativos (cada suministrador fomentará el uso del suyo propio), los

distribuidores de estos sistemas operativos ofrecen herramientas de desarrollo, son los

llamados kit de desarrollo de software (comúnmente llamadas SDK. También incluyen

las interfaces de usuario o UI) y las APIs.

Las APIs constituyen una pieza clave en el desarrollo de la aplicación, ya que es

a través de ellas, que el usuario (aplicación) interactúa con el sistema operativo. Hay que

tener en cuenta que todas las APIs no son iguales y que los recursos que necesitan son

distintos, así se puede diferenciar entre APIs de bajo nivel y de alto nivel, y su

conocimiento es fundamental para el desarrollo.

APIs de bajo nivel. Son las encargadas de controlar el hardware del dispositivo

móvil y las que tienen una relación más íntima con él y con su estructura física. Ofrecen

servicios más simples entre los que se inlcuyen interactuar con la pantalla táctil o teclado,

conectarse a redes, procesar y reproducir audio, recibir imágenes y vídeos, acceder al

GPS, gestionar archivos, etc.


19

APIs de alto nivel. Son las encargadas de proporcionar la experiencia móvil del

usuario. Como ejemplo incluye servicios como navegar por Internet, recibir y enviar

mensajes de texto, gestionar fotos y vídeos, hacer llamadas o videollamadas, etc. Otras

APIs de este nivel permiten acceder a servicios en la nube (compras y notificaciones

push).

Aparte de las APIs de bajo y alto nivel, existen otras específicas cuya finalidad es

la de definir la interfaz con el usuario denominadas herramientas de interfaz gráfica del

usuario (GUI). Al igual que en las otras APIs, cada suministrador de sistema operativo

móvil ofrece su propia configuración de botones, menús, barras de pestañas, sliders, etc.

y es a través de ellas por las que el usuario obtiene una mayor experiencia.

Conocer las APIs de cada plataforma y sus interfaces, así como ser capaz de

desarrollar código es el principal reto de un desarrollador de aplicaciones nativas. Más

aún, en el caso de que la aplicación sea multiplataforma.

Conocer y explotar las APIs nativas permiten que el usuario obtenga una mayor

experiencia, la gran ventaja de este enfoque. Las aplicaciones nativas son la única manera

de crear aplicaciones móviles completas que utilicen todas las funcionalidades que los

dispositivos móviles ofrecen.

Si bien se consigue una mayor experiencia, por contrapartida, la principal

desventaja es que el coste de desarrollo es mucho mayor. El código escrito para una

plataforma móvil no se puede usar en otra, por lo que el desarrollo y el mantenimiento de

aplicaciones nativas para múltiples sistema operativo conlleva mayores tiempos de

desarrollo, testeo y corrección de errores (ambos con su coste asociado).

Utilizar este enfoque en aplicaciones móviles es especialmente indicado cuando

se presentan algunos de los siguientes escenarios:

Aptitudes nativas existentes. Es menos costoso aprovechar las habilidades del

equipo de desarrollo que contratar o formar a uno nuevo.

Un único sistema operativo móvil. Cuando la aplicación está destinada a

ejecutarse en un sistema operativo concreto. Este puede ser el caso de la gran mayoría de

empresas, en las que los dispositivos que utilizan son iguales entre ellos.

Funcionalidad nativa. Cuando la aplicación a desarrollar necesita de una función

nativa.

Requisitos de una IU sofisticada. Muchas aplicaciones necesitan de una alta

experiencia del usuario, respuesta en tiempo real o gráficos de alto nivel (juegos).


20

2.2.2. Aplicaciones móviles basadas en la Web

Las aplicaciones móviles Web son aquellas que están basadas en los navegadores

móviles. Los navegadores actuales de los smartphones o pc tablets pueden ejecutar o

reproducir muchas nuevas funcionalidades de HTML5, CSS3 y JavaScript; con los

últimos avances logrados, HTML5 marca la transición de esta tecnología desde un

lenguaje de etiquetado a un poderoso estándar de desarrollo de aplicaciones complejas

basadas en navegador. Al emplear estas características y muchas otras que aún se

encuentran en desarrollo, los desarrolladores pueden crear aplicaciones avanzadas,

usando únicamente tecnologías basadas en la Web (IBM, 2012).

Algunas de las nuevas funcionalidades que contiene HTML5, junto con CSS3 y

JavaSript, es la disponibilidad offline (realmente interesante para los dispositivos

móviles, que tienen capacidades y recursos más limitados que otros dispositivos fijos),

acceso a APIs, entornos de desarrollo muy avanzados (herramientas basadas en

JavaScript, como dojox.mobile, Sencha Touch y jQuery Mobile), gestión de base de datos

en el navegador, etc. Todas estas funciones se ejecutan directamente en el navegador del

dispositivo móvil y no necesitan conectarse con el sistema operativo, como en el caso de

las aplicaciones nativas.

Incluso, los navegadores de los dispositivos pueden usarse a sí mismos como

aplicaciones nativas y acceder a APIs del sistema operativo, aunque el número de APIs

que son capaces de ejecutar son limitadas.

Existen dos enfoques para crear una aplicación móvil basada en Web. Para el

primero de ellos, sólo es necesario un acceso directo (idéntico al que se utiliza para lanzar

aplicaciones nativas) y se iniciará el navegador mostrando la página Web de destino. En

el segundo, consiste en adaptar la página Web a dispositivos móviles a través de páginas

Web sensibles al dispositivo que los visita. Al acceder al sitio Web requerido, se reconoce

el dispositivo de acceso (proyecto WURFL (Wireless Universal Resource FiLe), un

repositorio de información sobre dispositivos móviles y sus capacidades) (WURFL -

Mobile Device Database by ScientiaMobile, s.f.) y se cargan unas páginas HTML

optimizadas para una mejor experiencia.

Las expectativas futuras del sector en el uso de las tecnologías Web para

desarrollar aplicaciones móviles es que éstas cada vez sean más funcionales y de mayor

aplicación. El gran punto a destacar de las aplicaciones Web es su soporte para múltiples

plataformas y el bajo costo de desarrollo. La mayoría de los suministradores móviles

utilizan el mismo motor de búsqueda en sus navegadores, llamado WebKit, que es un

proyecto de fuente abierta conducido principalmente por Google y Apple y que ofrece la

más completa implementación de HTML5 disponible en la actualidad (IBM, 2012).

Lamentablemente, habrá que esperar un tiempo para ver el desarrollo de estas tecnologías.

Las funciones limitadas (actualmente, pero con una gran tendencia de desarrollo)

de HTML5, el acceso restringido a las API y la menor experiencia del usuario,

constituyen la principal desventaja de este enfoque frente a las aplicaciones nativas.


21

Las aplicaciones Web son, especialmente indicadas, cuando se presentan algunos

de los siguientes escenarios:

Distribución directa. Se quiere eliminar el tener que depender de las tiendas de

aplicación. La distribución y las actualizaciones de la aplicación son más rápidas y están

sometidas a menos restricciones.

Aplicación piloto. Desarrollar aplicaciones nativas para múltiples sistemas

operativos es muy costoso, una buena estrategia es probar el concepto de la aplicación y

la aceptación del mercado a través de tecnologías Web. Una vez se haya comprobado que

tiene buena aceptación y que cumple con los requisitos, se puede crear aplicaciones

nativas o incluso aprovechar el código desarrollado para crear aplicación híbridas.

Visibilidad. Las aplicaciones Web aparecen en los resultados de los buscadores,

es una ventaja (mayores usuarios potenciales) respecto a las tiendas de aplicaciones.

2.2.3. Aplicaciones híbridas

El enfoque intermedio entre el enfoque web y el enfoque nativo, es el enfoque

híbrido. Combinando tecnología Web con desarrollo nativo se puede conseguir lo mejor

de los dos mundos, se pueden desarrollar aplicaciones multiplataforma (ahorrando coste

y tiempo de desarrollo) y acceder a APIs nativas cuando sea necesario (mejorando la

experiencia del usuario).

La porción nativa de la aplicación emplea APIs de sistemas operativos para crear

un motor de búsqueda HTML incorporado que funcione como un puente entre el

navegador y las APIs del dispositivo (IBM, 2012).

Los desarrolladores pueden optar por codificar su propio puente (aprovechando

conocimiento nativos) o bien aprovechar algunas soluciones que el mercado ofrece (cada

vez emergen más soluciones), lo que brinda al desarrollador formas de crear una

aplicación avanzada que utilice todas las funciones del dispositivo usando únicamente

lenguajes Web. De estas soluciones destacan PhoneGap, Upplication, Octopusapps,

Appmachine, Appmkr, Mobincube, Yapp o Appbuilder.

Las dos opciones para desarrollar la porción Web de la aplicación son el

alojamiento del código en un servidor o el almacenamiento local en el dispositivo y el

uso de una u otra opción dependerá de los requisitos de la aplicación. Con el código

HTML alojado en un servidor es posible hacer pequeñas actualizaciones en la aplicación,

pero al tener la necesidad de estar conectado a Internet, la aplicación no dispondrá de

modo offline. Con la incorporación del código en la aplicación se mejora el rendimiento,

la experiencia del usuario y la accesibilidad, pero no son posibles las actualizaciones

remotas.

Lógicamente, no es necesariamente estricto elegir entre estos dos enfoques y se

puede elegir una solución intermedia. En un servidor Web se puede alojar el código


22

HTML y los recursos necesarios, mejorando así las actualizaciones y la flexibilidad, y

almacenar localmente éstos recursos para mejorar la usabilidad y el rendimiento.

Las aplicaciones híbridas son, especialmente indicadas, cuando se presentan

algunos de los siguientes escenarios:

Lograr un término medio. Se puede obtener los beneficios de los dos enfoques. Se

puede mejorar la experiencia del usuario y la funcionalidad de la aplicación a través del

puente nativo y conseguir una distribución multiplataforma (mejorando tiempos de

desarrollo y costes) a través de tecnología Web.

Capacidades de los desarrolladores. Es más fácil encontrar desarrolladores

especializados en tecnologías Web (principalmente, HTML, CSS y JavaScript), que son

los que desarrollan el grueso de la aplicación, que desarrolladores que conozcan lenguajes

nativos de sistemas operativos móviles.

Expectativas futuras. La tendencia creciente en el uso de HTML5 gracias a su

fácil desarrollo y a la aparición de cada vez más funciones, y la posibilidad de usar código

nativo cuando sea necesario, puede hacer que la tecnología por excelencia para el

desarrollo de aplicaciones móviles sea la híbrida.

2.2.4. Comparación de los distintos enfoques.

A modo de resumen, y para ayudar en la elección de un enfoque, se puede concluir

que:

El enfoque nativo se destaca por su desempeño y acceso de los dispositivos, pero

conlleva costes y requiere actualizaciones y/o adaptaciones entre plataformas. Desde el

punto de vista del desarrollo, es muy caro dar soporte multiplataforma (I. Wasserman,

2010).

El enfoque Web es mucho más simple, menos costoso y más fácil de actualizar,

pero actualmente su funcionalidad es limitada y no puede alcanzar un alto nivel de

experiencia del usuario como en el caso de las llamadas API nativas. También es notable

decir que las tecnologías Web siguen una tendencia creciente en su uso para desarrollar

aplicaciones móviles.

El enfoque híbrido ofrece un término medio que, en muchas situaciones,

constituye lo mejor de ambos mundos, en especial si el desarrollador desea emplearlo en

múltiples sistemas operativos.

A la hora de decidir un enfoque u otro para la aplicación, será clave el encontrar

un punto medio, por un lado, entre la experiencia del usuario que proporciona las

aplicaciones nativas y la disponibilidad de funciones de las aplicaciones en el caso de usar

tecnologías web, y, por el otro, entre los costes de desarrollo de aplicaciones nativas


23

multiplataforma y el tiempo de salida al mercado (si se desea utilizar un prototipo para

evaluar de una manera tempranal la aceptación del mercado o no).


24

2.3. Estrategia de desarrollo de aplicaciones móviles

Los desarrollos móviles se caracterizan por su corta duración. El ritmo en el que

aparecen novedades es altísimo (constantemente están apareciendo nuevos dispositivos,

nuevas funciones de HTML, nuevos SDK y UI en los que muchos de ellos no es necesario

ni saber programar, nuevas soluciones comerciales para aplicaciones nativas, web o

híbridas, etc) y la competencia del sector (es posibles lanzar aplicaciones al mercado sin

mucho desarrollo, muchos desarrolladores e incluso aficionados con ideas se han lanzado

a desarrollar aplicaciones móviles) hacen que el tiempo de desarrollo de una aplicación

móvil tenga que ser muy corto. Estimado en unas 18 semanas para Android, iOS y HTML

(Kinvey, 2013).

En el mundo del desarrollo de aplicaciones móviles, al igual que en el desarrollo

de software, existen muchos métodos de desarrollo, cada uno con sus puntos fuertes y sus

puntos débiles. Algunos de los métodos más conocidos son los siguientes:

Modelo en cascada

Modelo rápido de aplicaciones

Desarrollo ágil

Mobile-D

Diseño centrado en el usuario

2.3.1. Modelo en cascada

Es el modelo tradicional de desarrollo. El modelo de cascada se usa para pequeños

programas donde los requisitos del sistema están muy claros, e incluso también lo está la

solución conceptual. Tras pensar brevemente como sería el desarrollo, se pasa

directamente a la codificación (Framiñan Torres, 2008). Son desarrollos con muy poca

incertidumbre o similares a otros ya realizados.

El proyecto es una suma de tareas secuenciales, en donde el output de una fase es

el input de la siguiente y no existe el solape entre ellas. Al ser proyectos con poca

incertidumbre y de duraciones y costes fáciles de estimar, la planificación y el

presupuesto son las variables fundamentales a controlar del proyecto.

Mencionar que el carácter estático de este modelo, hará que en la fase de

mantenimiento se tenga que invertir más tiempo y esfuerzo.


25

2.3.2. Desarrollo rápido de aplicaciones

El objetivo primordial de este modelo es desarrollar prototipos lo antes posible de

manera que se pueda evaluar el producto y concepto en su conjunto, e incluso se pueda

colocar en el mercado y obtener conclusiones tempranas de la aceptación de los usuarios.

Después del primer prototipo se sigue trabajando en mejorar y lanzar nuevas versiones.

Se utilizan en proyectos en los que los requisitos no están muy claros y muchos

de ellos se irán estableciendo durante la fase de implementación y en proyectos con

tiempos de desarrollo muy cortos, proyectos que son realmente urgentes.

2.3.3. Desarrollo ágil

Es un modelo basado en iteraciones y especialmente indicado para proyectos con

incertidumbre, en los que no están claros los requisitos y en los que se quiera un desarrollo

rápido. En este modelo, en cada iteración se desarrollan todas las fases del proyecto

(modelo incremental), se busca la excelencia en la calidad (a través de automatizaciones

y de aumentar las pruebas de la fase de testeo) y se centra más en la ejecución que en los

planes.

La filosofía detrás de esta metodología se refleja en el manifiesto ágil que

acordaron muchos de los desarrolladores líderes de estos métodos (Sommerville, 2011):

Se da más valor a los individuos y a sus interacciones que a los procesos

y herramientas.

Se da más valor al software operativo que a la documentación exhaustiva.

Se da más valor a la colaboración del cliente que a la negociación del

contrato.

Se da más valor a la respuesta al cambio y a los problemas que al

seguimiento de un plan.

El desarrollo ágil es especialmente indicado cuando se presentan algunos de los

siguientes escenarios:

Proyectos cambiantes y con requisitos no claros. Este método permite mayor

flexibilidad ante cambios de requisitos, problemas técnicos y cambios del entorno

(nuevos dispositivos, nuevas tecnologías, nuevos competidores, etc.).

Ciclos de desarrollo cortos. Para aplicaciones que se quieran colocar pronto en el

mercado.


26

Equipos de desarrollo pequeños. Los proyectos pequeños tienen menos inercia

ante los cambios, aumentando la flexibilidad.

Software no crítico. Las aplicaciones móviles no suelen ser grandes desarrollos

(aplicaciones de entretenimiento, pequeños juegos, gestión a muy pequeña escala, redes

sociales, etc.).

2.3.4. Mobile-D

El objetivo de este método es conseguir ciclos de desarrollos muy rápidos en

equipos muy pequeños (de no más de diez desarrolladores) trabajando en un mismo

espacio físico. Según este método, trabajando de esa manera se deben conseguir

productos totalmente funcionales en menos de diez semanas (Ramírez Vique, 2013).

2.3.4.1. Ciclo de desarrollo de Mobile-D

El ciclo siempre comienza con un día de planificación y termina con un

día de entrega, y, a modo de resumen, se explica a continuación y brevemente, las

fases que componen el método:

Fase de exploración. Se define el proyecto conceptualmente y se establece

la planificación.

Fase de inicialización. En esta fase se analizan los recursos y los planes

necesarios para poder abarcar el proyecto.

Fase de producto. Hasta conseguir el primer desarrollo, se reiteran todas

las subfases que lo componen (todas las fases contienen un día de planificación,

un día de trabajo y un día de entrega). Para obtener la máxima calidad posible se

utilizan técnicas como la del test driven development.

Fase de estabilización. Todos los códigos desarrollados se unen y

ensamblan para la posterior fase de pruebas.

Fase de pruebas y reparación. Se testea la aplicación y se solucionan los

problemas que surgen de manera que se pueda tener una aplicación funcional

acorde a los requisitos.

2.3.5. Diseño centrado en el usuario

El diseño centrado en el usuario (DCU) consiste en desarrollar productos que

cubran las necesidades de los usuarios consiguiendo que queden satisfechos y se sientan

cómodos usándolos. El diseño centrado en el usuario supone incluir al usuario en todo el

proceso de desarrollo, haciéndole participar y teniendo en cuenta su opinión (Pintos

Fernández, 2014). Desde la captura de requisitos (en la que el usuario es fundamental)


27

hasta el diseño de la aplicación, la navegación, etc, (donde se busca la usabilidad y el

hacer la aplicación más atractiva), el usuario es la clave y el factor diferenciador.

La principal diferencia de este método frente al resto de métodos descritos está en

que el usuario participa activamente desde el principio del desarrollo aportando

opiniones, y no sólo lo hace al final y una vez desarrollada la aplicación, cuando ya poco

beneficio puede aportar.

2.3.5.1. Proceso del DCU

El proceso del DCU es cíclico, está basado en iteraciones y en que las

aportaciones de los usuarios en las fases de diseño son clave para satisfacer los

requisitos.

La base de muchas de las metodologías DCU está basada en un estándar

internacional, la ISO 13407 y que se caracterizan por (Ferré Grau, 2015):

La implicación activa de usuarios.

Una clara comprensión de los requisitos del usuario y sus tareas.

Una adecuada asignación de funciones entre los usuarios y la

tecnología.

La iteración de soluciones de diseño.

Un diseño multidisciplinar.

Dicho estándar ofrece una guía para facilitar el logro de una mayor calidad

en el uso de sistemas interactivos incorporando diseño centrado en el usuario y

describe cuatro actividades principales que se tienen que seguir (Ferré Grau,

2015):

Identificar los usuarios y su contexto de uso.

Establecer los requisitos de los usuarios y organizativos.

Producción de soluciones de diseño.

Testeo y evaluaciones del diseño. Comprobar si, efectivamente, el

desarrollo cumple con los requisitos o solucionar los problemas

puedan surgir de esta fase.


28

El proceso finaliza una vez se han satisfecho todos los requisitos y

objetivos marcados al inicio del proyecto.

2.3.6. Comparación de los distintos métodos

A modo de resumen, se puede concluir que:

El modelo en cascada se utiliza en desarrollos pequeños en los que los

requisitos están claros y existe poca incertidumbre.

Los modelos desarrollo rápido de aplicaciones, desarrollo ágil y Mobile-

D son especialmente aplicables para desarrollos rápidos y bajo mucha

incertidumbre. Estas metodologías están más orientadas a la ejecución para

conseguir una rápida colocación en el mercado y tiempos de desarrollo más cortos.

El diseño centrado en el usuario se usa para conseguir desarrollos más

usables y en los que el usuario aporta mayor valor.

Usuarios y contexto

Especificar requisitos

Producir soluciones de diseño

Testeo y evaluación El sistema satisface

los requisitos

Ilustración 2. Proceso del diseño centrado en el usuario (DCU)



Capítulo 3. Diseño de la aplicación

Noticias Jurídicas

Capítulo 3. Diseño de la aplicación Noticias Jurídicas José Luis Olivares Rodríguez

30

Tomando como base todo el estudio realizado en el Capítulo 2, durante el presente

capítulo se detalla los usuarios potenciales de la aplicación y el contexto bajo el que

usaran la aplicación, los requisitos que tiene que satisfacer y su diseño en sí.

El capítulo se va a desarrollar siguiendo la metodología de diseño centrada en el

usuario con el objetivo de conseguir una alta aceptación de la aplicación por los usuarios

a través de la usabilidad y el diseño. La usabilidad es un tema crítico para la aceptación

de un sistema, si el sistema no es percibido como una herramienta que ayude al usuario a

realizar sus tareas, se dificulta la aceptación del sistema pudiendo llegar a no usarse o a

usarse con escasa eficiencia (Ferré Grau, 2015). La aplicación debe ser diseñada para una

navegación sencilla e intuitiva sin ningún tutorial o ayuda adicional (K. Flora, Wang, &

V. Chande, 2014).

Al incluir al usuario en todo el proceso de desarrollo, se persigue mejorar la

usabilidad y el diseño, factores clave del éxito de la aplicación y factores diferenciadores

respecto al uso del portal Web.

Concretamente y en términos de diseño, la aplicación será diseñada para que

incluya dos funciones clave definidas por los usuarios y que no están disponibles en el

portal Web. La primera de ellas es la posibilidad de hacer búsquedas más precisas a través

de un formulario diseñado específicamente por y para los usuarios. La segunda, es la

posibilidad de gestionar información (noticias o extractos de noticias) relevante para ellos

a través de una sencilla base de datos.

Concretamente y en términos de usabilidad, todo el diseño gráfico estará

orientado a obtener una interfaz atractiva y una navegación sencilla e intuitiva que

aumente la satisfacción y la fidelización del usuario.

También mencionar que la aplicación tendrá disponibilidad online y que la

ubicuidad de los dispositivos móviles, ya explicada, supone una ventaja competitiva

frente al portal Web.

3.1. Usuarios de la aplicación y contexto

La aplicación está destinada principalmente a aquellos usuarios que necesiten o

requieran de cualquier información en materia jurídica en España. La mayor parte de estos

usuarios serán los propios usuarios de la web “Noticias Jurídicas”.

La web “Noticias Jurídicas” es la segunda web más visitada en materias jurídicas

en España (según ranking del contador universal ALEXA) (Notarios y Registradores:

Portal jurídico, s.f.) con 51.505 visitantes diarios y 309.030 páginas mostradas (ALEXA,

s.f.); sólo por detrás del “Boletín Oficial del Estado” y por delante de páginas tan

importantes como el “Legalitas”, “Ministerio de Justicia” y “Congreso de los diputados”.

Concretizando dentro del público objetivo, se puede destacar que los principales

usuarios de la aplicación serán estudiantes y ejercientes de las siguientes profesiones:


31

Abogados

Notarios

Registradores de la propiedad y mercantiles

Procuradores de los tribunales

Secretarios Judiciales

Jueces y Magistrados

Graduados sociales

Inspectores de trabajo

Inspectores de hacienda

Profesionales de recursos humanos

Profesionales de la administración de empresas

Profesionales de la administración pública

Políticos

Directivos

Representantes sindicales

El contexto de uso, al igual que en muchas otras aplicaciones móviles, es de

consulta de información y pequeñas transacciones. Un símil de contexto es cualquier

aplicación de correo electrónico, la cual se usa para leer correos, contestar correos

urgentes o correos que conlleven poco tiempo de elaboración en la respuesta; pero no se

utiliza como referente de manera prolongada.

De igual modo que en el ejemplo, no se espera que la aplicación sea utilizada para

trabajar de forma continuada o prolongada, ya que para ello los dispositivos fijos son más

prácticos y eficaces.


32

3.2. Captura de requisitos

La captura de requisitos es el proceso por el cual se establece qué requisitos y

funciones debe satisfacer la aplicación, así como los recursos organizativos (perfiles)

necesarios para ello.

3.2.1. Requisitos organizativos

Por etapa del proyecto y al ser un desarrollo pequeño, los requisitos organizativos

o humanos los formarían los siguientes perfiles:

Diseño. Director de proyecto y grupo de usuarios finales (como

partícipes).

Implementación. Director de proyecto y programador/diseñador gráfico.

Testeo. Director de proyecto, programador/diseñador gráfico y grupo de

usuarios finales (como partícipes).

Comercialización. Director de proyecto.

3.2.2. Requisitos estratégicos

A nivel estratégico la aplicación debe reducir el coste por fragmentación y el coste

de desarrollo, los dos grandes problemas explicados en el Capítulo 2, y acceder al máximo

número de usuarios.

3.2.3. Requisitos del usuario

Para la captura de requisitos se van a utilizar casos de uso, que describirán una

acción o requerimiento del usuario (actor) que la aplicación debe satisfacer.

Posteriormente estos casos de uso y las relaciones entre todos ellos, se representarán en

un diagrama de casos de uso que constituirá la base funcional de la aplicación.

La aplicación sólo va a tener un actor que serán los usuarios finales y cuyos casos

de uso han sido definidos conjuntamente con los propios usuarios. Son:

Ver la página principal de la web “Noticias Jurídicas”.

Navegar a través de las secciones de la web “Noticias Jurídicas”.

Buscar contenido acorde a criterios específicos dentro de la web “Noticias

Jurídicas”.


33

Ver y personalizar las secciones “Favoritos” de la aplicación y eliminar

noticias de “Favoritos”.

Añadir noticias a las secciones “Favoritos” de la aplicación.

Guardar noticias en el dispositivo como enlaces.

Guardar noticias o extractos de noticias en el dispositivo como PDF.

Enviar noticias como enlaces o PDF o extractos de noticias como texto o

PDF.

Gestionar las noticias guardadas.

3.3. Producción de la solución. Diseño de la aplicación “Noticias Jurídicas”

3.3.1. Solución estratégica

Para cumplir con los requisitos estratégicos y después de la revisión del Capítulo

2, el mejor planteamiento para la aplicación es que sea híbrida. Con una aplicación híbrida

se puede aprovechar las tecnologías Web para elaborar el grueso de la aplicación, de

manera que se reduce el tiempo y el coste de desarrollo por ser una tecnología bien

conocida por muchos desarrolladores y para acceder a un mayor número de usuarios por

ser multiplataforma. La aplicación se diseñará para estar disponible al menos para

Android e iOS, que conjuntamente poseen el 96,3 % de la cuota de mercado.

La parte nativa se utilizará para mejorar la experiencia del usuario a través del

puente comercial Mobincube, que ofrece la posibilidad de crear aplicaciones Android,

iOS, Windows y acceso de usuarios web. Dispone de funcionalidades como

disponibilidad offline, desarrollo de bases de datos, RSS y monetización.

El potencial de los puentes nativos comerciales son las numerosas llamadas a API

nativas que ofrecen y la posibilidad de desarrollar nueva, así como la disponibilidad de

un servicio técnico que pueden ejercer como consultores durante cualquier desarrollo.

3.3.2. Diagrama de Casos de Uso

El diagrama de casos de uso está compuesto por todos los casos de uso definidos

por el usuario y por dos casos de uso adicionales para gestionar las noticias guardadas.

Ellos son “Modificar noticas guardadas” y “Eliminar noticias guardadas”.

En el diagrama de casos de uso de la Ilustración 3 se detallan las relaciones entre

usuario y casos de uso y entre casos de uso. Uno de los dos aspectos más importantes del

diagrama es el caso de uso “Gestionar las noticias guardadas”, mediante el cual el actor


34

podrá consultar el estado de las noticias guardadas, modificar alguno de sus atributos,

eliminar noticias, enviar noticias guardadas o generar PDFs de noticias guardadas. El otro

aspecto importante es que en los casos de uso “Añadir noticias a las secciones “Favoritos”

y “Guardar noticias o extractos de noticias en el dispositivo como PDF”, estarán

disponibles tanto para noticias nuevas (se invoca el caso de uso “Guardar noticias como

enlaces”) como para noticias ya guardadas (se invoca el caso de uso “Modificar noticias

guardadas”).


35

Ilustración 3. Diagrama de Casos de Uso


36

3.3.3. Diagramas de Actividad de Casos de Uso

De entre las distintas maneras de representar un caso de uso, para este proyecto se

van a utilizar los diagramas de actividad, por ser una manera fácil de seguir visualmente

el flujo de tareas que tienen que realizar los actores y la aplicación para ejecutar el caso

de uso.

En cada diagrama de actividad se representa la interacción actor-aplicación a

través de las distintas tareas que realizan cada uno. Cada tarea de la aplicación está

relacionada con una clase que puede ser “Pantallas”, “Control” o “Formulario”, mientras

que para el usuario solo se establece la clase “Acción” para determinadas actividades.

Pantalla. Las pantallas representan la interfaz entre el usuario y el sistema

y es mediante ellas que el usuario puede interactuar con el sistema requiriendo

información o alguna acción por parte de la aplicación. Todas las pantallas

representadas en los diagramas de actividades son pantallas con contenido

dinámico y que en su mayor parte corresponderá a consultas sobre las noticias

guardadas y a visualizar contenido de la web “Noticias Jurídicas”.

Formulario. Un formulario es una parte de una pantalla en la que el usuario

puede introducir datos que, posteriormente, la aplicación usará para realizar

alguna acción.

Control. Bajo esta clase se engloban a aquellas actividades de los casos de

uso que se traducen en realizar alguna operación por la aplicación.

Acción. Corresponde a aquellas actividades de los casos de uso por medio

de las cuáles el usuario invoca un caso de uso o solicita una operación al sistema

a través de alguna acción sobre la pantalla (arrastrar un ítem, presionar un botón,

mover o girar el dispositivo móvil, etc.)

3.3.3.1. Ver la página principal de la web “Noticias Jurídicas”

El usuario, presionando el “Botón Principal”, solicita ver la página

principal de la web “Noticias Jurídicas” y para ello, la aplicación realiza la

operación “Llamar API navegador predeterminado”. Mediante esta operación, se

abre el navegador predeterminado del dispositivo móvil y se carga la página web

solicitada. Finalmente la información es mostrada a través de la pantalla

“Principal”


37

3.3.3.2. Navegar a través de las secciones de la web “Noticias

Jurídicas”

El usuario, presionando el “Botón Secciones”, solicita ver una de las

secciones de la web “Noticias Jurídicas” y para ello, la aplicación realiza la

operación “Llamar API navegador predeterminado”. Mediante esta operación, se

abre el navegador predeterminado del dispositivo móvil y se carga la sección de

la página web solicitada. Finalmente la información es mostrada a través de la

pantalla “Secciones”.

Ilustración 4. Ver la página principal de la web “Noticias Jurídicas”


38

3.3.3.3. Buscar contenido acorde a criterios específicos dentro de la

web “Noticias Jurídicas”

Al presionar el usuario el “Botón Búsqueda”, la aplicación muestra un

formulario con los parámetros “Nombre”, “Sección”, “Tipo de norma”,

“Número”, “Órgano de creación”, “Fecha de publicación” y “Vigencia” y que el

usuario rellena acorde a sus criterios de búsqueda. Posteriormente la aplicación

realiza una búsqueda dentro de la web “Noticias Jurídicas” (ya sea la página

principal o alguna de sus secciones) con los datos rellenados por el usuario y

muestra los resultados sobre la misma pantalla.

Ilustración 5. Navegar a través de las secciones de la web “Noticias Jurídicas”


39

3.3.3.4. Ver y personalizar las secciones de “Favoritos” de la

aplicación y eliminar noticias de “Favoritos”

Presionando el “Botón Favoritos” el usuario solicita ver las noticias

guardadas en “Favoritos” y la aplicación consulta su estado y lo muestra en la

pantalla “Favoritos”. Entonces, el usuario decide si quiere personalizar alguna de

las tres subsecciones de “Favoritos” y la aplicación aplica los cambios o eliminar

alguna noticia guardada en “Favoritos” y elimina la noticia de “Favoritos”.

Cualquiera de las dos acciones, convoca al caso de uso “Modificar noticias

guardadas”, en dónde se actualizará el atributo “Sección Favoritos” de todas las

noticias guardadas afectadas.

Ilustración 6. Buscar contenido acorde a criterios específicos dentro de la web “Noticias Jurídicas”


40

3.3.3.5. Añadir noticias a las secciones “Favoritos” de la aplicación

El usuario podrá añadir noticias a cualquiera de las subsecciones de

“Favoritos” arrastrando la noticia hacia la subsección deseada. La noticia puede

ser una noticia ya guardada (se modifica el atributo de la noticia con el caso de

uso “Modifica noticias guardadas”) o una noticia nueva (se convoca el caso de

uso “Guardar noticias como enlaces”).

Ilustración 7. Ver y personalizar las secciones de “Favoritos” de la aplicación y eliminar noticias de “Favoritos”


41

3.3.3.6. Enviar noticias como enlaces o PDF o extractos de noticias

como texto o PDF.

El usuario solicita enviar un texto seleccionado o una noticia completa

presionando el “Botón Compartir” o desde el caso de uso “Gestionar noticias

guardadas” se ha solicitado el envío de una noticia en PDF. A través del puente

nativo, la aplicación llama a la API “Compartir”, el usuario selecciona uno de los

medios disponibles y la aplicación realiza la operación.

Ilustración 8. Añadir noticias a las secciones “Favoritos” de la aplicación


42

3.3.3.7. Guardar noticias como enlaces

A través del “Botón Guardar” el usuario puede guardar una noticia en la

base de datos y para ello, la aplicación realiza dos operaciones. La primera es la

extracción de los atributos de la noticia y la segunda es añadir un registro con la

noticia y todos sus atributos.

Ilustración 9. Enviar noticias como enlaces o PDF o extractos de noticias como texto o PDF


43

3.3.3.8. Gestionar las noticias guardadas

A través de este caso de uso el usuario puede gestionar las noticias

guardadas, ya sea modificando algún atributo, eliminando noticias, generando

PDF de noticias guardadas y/o enviandolas o simplemente consultar el estado de

las noticias.

Para ello, primero la aplicación realiza una consulta a la base de datos y

muestra los resultados al usuario. Después el usuario solicita alguna de las

acciones nombradas previamente, presionando los distintos botones que estarán

disponibles (“Eliminar”, “Compartir” o “Genera PDF”) o simplemente

modificando atributos sobre la pantalla. Estas acciones del usuario invocan a

distintos casos de uso en función de su elección, ellos son “Modificar las noticias

guardadas”, “Eliminar noticias guardadas”, “Enviar noticias o extractos de

noticias como PDF” o “Guardar noticias o extractos de noticias como PDF”.

Ilustración 10. Guardar noticias como enlaces


44

3.3.3.9. Modificar noticas guardadas

Este caso de uso modifica los atributos de las noticias guardadas. El interés

de crear un caso de uso sólo para una acción, está en que para futuras versiones

de la aplicación se puede aumentar su funcionalidad sin que el resto de casos de

usos se vean afectados.

Ilustración 11. Gestionar las noticias guardadas

Ilustración 12. Modificar noticias guardadas


45

3.3.3.10. Eliminar noticias guardadas

Una vez el usuario solicita la eliminación de la noticia en el caso de uso

“Gestionar las noticias guardadas”, la aplicación elimina el registro de la base de

datos, así como su PDF asociado en el caso de que lo tuviese.

Ilustración 13. Eliminar noticias guardadas


46

3.3.3.11. Guardar noticias o extractos de noticias en el dispositivo

como PDF

La idea de no incluir la posibilidad de generar un PDF de la noticia en el

caso de uso “Guardar noticias como enlace” es que el usuario tenga la posibilidad

de guardar directamente la noticia como PDF a través de una acción, presionando

el “Botón Genera PDF”.

Esta operación estará disponible tanto para noticias ya guardadas

(modificando sus atributos en consecuencia) o para noticias nuevas (convocando

el caso de uso “Guardar noticias como enlaces”). Para ello la aplicación hará una

llamada API a la impresora PDF y guardará el archivo en el dispositivo.

Ilustración 14. Guardar noticias o extractos de noticias en el dispositivo como PDF


47

3.3.4. Captura de la experiencia del usuario

En esta fase se define cómo será la experiencia del usuario tanto a nivel funcional

como a nivel gráfico y su output es obtener el mapa de navegación y el diseño gráfico de

las pantallas y del formulario.

Esta fase, además de presentarle la aplicación al usuario, valida la fase de captura

de requisitos.

3.3.4.1. Mapa de navegación

En el mapa de navegación viene representadas todas las clases pantallas y la

navegabilidad entre ellas, es decir, el flujo de pantallas que le aparecerá al usuario en

función de sus acciones.

El diseño del mapa de navegación está basado en 4 pantallas principales que

corresponden a 4 secciones diferenciadas de la aplicación. Tanto las secciones como las

pantallas se denominan igual y son “Principal”, “Secciones”, “Favoritos” y “Consulta”.

En la pantalla “Principal” y “Secciones” estará disponible el “Botón Búsqueda”

que muestra la pantalla “P_búsqueda” asociada al formulario “Búsqueda”. Una vez el

usuario ha introducido sus criterios de búsqueda y la aplicación ha realizado la operación,

el resultado de la búsqueda se muestra en la pantalla “Resultado”, que es la combinación

de una de las pantallas “Principal” o “Secciones” y los resultados de la búsqueda.

En la pantalla “Favoritos” se muestran 3 subsecciones que puede personalizar el

usuario y que muestra las noticias (descripción y URL para acceder a ella) que el usuario

ha añadido a favoritos.

En la pantalla “Consulta” se muestra una consulta del estado de las noticias

guardadas y es desde esta pantalla en la que el usuario puede gestionar sus noticias

guardadas (eliminar, modificar, generar PDF o enviar).

Por último cabe destacar, que las 4 pantallas principales estarán disponibles en

cualquier momento simplemente pulsando su botón correspondiente y que la página de

inicia será la pantalla “Principal”.

En lo relativo al resto de botones, los que permiten que el usuario realice alguna

acción sobre una noticia o sobre un extracto, decir que aparecen cuando el usuario

presione la noticia o seleccione el extracto y que su disponibilidad depende de la pantalla

desde la que el usuario realce la acción:

Pantalla “Principal” y “Secciones”: Botón “Compartir”, Botón “Guardar”,

Botón “Genera PDF”.


48

Pantalla “Favoritos”: Botón “Eliminar”.

Pantalla “Consulta”: Botón “Compartir”, Botón “Eliminar”, Botón “Genera

PDF”.


49

Ilustración 15. Mapa de navegación


50

Ilustración 16. Pantalla "Principal". Ejemplo 1


51

Ilustración 17. Pantalla "Principal". Ejemplo 2


52

Ilustración 18. Pantalla "Secciones". Ejemplo 1


53

Ilustración 19. Pantalla "Secciones". Ejemplo 2


54

Ilustración 20. Pantalla "Favoritos"

Jurisprudencia Laboral Sección3


55

Ilustración 21. Pantalla "Consulta"

ID

Favoritos

Descripción

URL PDF


56

Ilustración 22. Formulario “Búsqueda”. Ejemplo 1

Ilustración 23. Formulario “Búsqueda”. Ejemplo 2


57

3.3.5. Modelo de clases de análisis

En el modelo de clases de análisis se representan los distintos elementos que

transforman los requisitos de la aplicación en funcionalidades. Estos elementos se

categorizan en boundary (representan la interfaz usuario y aplicación), control (son las

operaciones del sistema) y entity (representan los elementos persistentes en la aplicación,

los datos de las bases de datos).

El elemento entity de la aplicación es la “Noticia” (noticia guardada) y posee los

atributos Identificador de noticias, Sección Favoritos, Descripción, URL y PDF:

Identificador de noticias (clave primaria). Secuencia numérica que define

inequívocamente a cada noticia.

Sección Favoritos. Tomará los valores de la subsección a la que pertenecen

o “” (vacío) si no pertenece a ninguna subsección.

Descripción. Se guardará el titular de la noticia

URL. Se guardará la dirección URL de la noticia.

PDF. Tomando los valores “Sí” o “No”, representará si la noticia está

guardada como PDF.

Muchos de los elementos control de la aplicación están diseñados para actuar

sobre la entity “Noticia”, pudiendo cambiar atributos, eliminar datos o añadir nuevos:

Añadir noticia nueva. Crea un nuevo registro de una noticia con los

atributos extraídos previamente.

Cambiar parámetros de noticias. Esta operación permite al usuario la

posibilidad de modificar los atributos “Sección Favoritos”, “Descripción”

y “URL”.

Modificar nombres sección. Modifica los valores de la “Sección

Favoritos”.

Guardar noticia PDF. Permite generar el PDF de una noticia guardada,

cambiando su atributo “PDF” de “No” a “Sí”.

Consultar estado noticias guardadas en “Favoritos”. Muestra una

consulta sobre la pantalla “Favoritos” de las noticias guardadas en

Favoritos.


58

Consultar estado noticias. Muestra una consulta sobre la pantalla

“Consulta” de todas las noticias guardadas.

Eliminar noticias. Elimina el registro de las noticias requeridas.

Tanto la entity “Noticia” como sus control asociados son los elementos más

importantes del modelo de clases de análisis representado en la Ilustración 24. Modelo de

clases de análisis.


59

Ilustración 24. Modelo de clases de análisis



Capítulo 4. Conclusiones y futuras

líneas de trabajo

Capítulo 4. Conclusiones y futuras líneas de trabajo José Luis Olivares Rodríguez

61

4.1. Conclusiones del trabajo

Para concluir este trabajo fin de máster he querido evaluar la aplicación “Noticias

Jurídicas” desde un punto de vista más amplio, como un futuro proyecto empresarial, y

no sólo centrarme en el diseño en sí, objetivo de este proyecto. Para determinar la

viabilidad técnica y de mercado del proyecto (se queda fuera del alcance del proyecto la

viabilidad económica-financiera), he optado por realizar un análisis estratégico y

mostrarlo en una matriz DAFO para después obtener una conclusión.

Tabla 2. Matriz DAFO

4.1.1. Amenazas

Aspectos legales y jurídicos. Es la amenaza más significativa del futuro proyecto

empresarial, afectando a todo el diseño gráfico por completo incurriendo en costes de

desarrollo o incluso podría conllevar la no comercialización.

Fragmentación del sector. Aunque la aplicación está diseñada para que sea

multiplataforma, pueden surgir nuevos dispositivos, tecnologías, versiones de sistemas

operativos, etc. que provoquen la no disponibilidad de la aplicación perdiendo cuota de

mercado o incurriendo en costes de adaptación.

4.1.2. Oportunidades

Crecimiento del sector. En el mundo ya se disponen de 7.300 millones de

teléfonos móviles y el sector creció un 28,4% frente al año anterior. En España el número

de líneas móviles superó los 50,6 millones y el sector creció un 1,2% respecto al año

anterior.

Amenazas Oportunidades

Aspectos legales y jurídicos

Fragmentación del sector

Crecimiento del sector

Ubicuidad de los dispositivos

móviles

Enfoque de web adaptado a móviles

del portal Web

Usuarios potenciales

Debilidades Fortalezas

Problemas técnicos: Llamada API a

la impresión PDF

Imprevistos en la implantación

Coste de desarrollo

Multiplataforma

Diseño y usabilidad


62

Ubicuidad de los dispositivos móviles. El uso más práctico de los dispositivos

móviles ha hecho que los usuarios los usen como accesorio diario tanto en lo profesional

como en lo personal.

Enfoque de web adaptado a móviles del portal Web. El portal Web ha optado por

desarrollar este enfoque, reduciendo la probabilidad casi a cero de que desarrollen una

aplicación que pueda competir con la desarrollada en este proyecto.

Usuarios potenciales. Es una gran oportunidad, porque no hay que invertir mucho

tiempo ni dinero en acceder a un grupo de usuarios potenciales. Son los propios usuarios

de la web los que forman este grupo con 51.505 visitantes diarios.

4.1.3. Debilidades

Problemas técnicos: “Llamada API a la impresión PDF”. Pueden surgir

problemas en este sentido debido a que todavía no hay muchas aplicaciones o llamadas

API suficientemente maduras que posibiliten las impresiones PDF. Si no fuera posible

desarrollar esta llamada API, habría que buscar otras opciones como la impresión

amigable de las páginas web. Esto podría derivar en extra costes de desarrollo.

Imprevistos en la implantación. En la implantación surgirán imprevistos a los que

hay que hacer frente.

4.1.4. Oportunidades

Coste de desarrollo. Las tecnologías Web son más baratas y más conocidas por el

que el coste y el tiempo de desarrollo son menores.

Multiplataforma. La aplicación estará disponible para Android, iOS, Windows

Mobile y usuarios Web. Android e iOS conjuntamente poseen el 96,3% de la cuota de

mercado, lo que supone un acceso casi completo a nivel de sistemas operativos.

Diseño y usabilidad. Gracias a la participación activa de los usuarios se pretende

conseguir una alta aceptación de la aplicación.

4.1.5. Conclusión

El principal riesgo de la aplicación y el único que podría ocasionar su no

comercialización, y por ente, que no sea viable, son los aspectos legales por el uso

de información del portal Web. Antes de comenzar con la fase de implantación es

necesario estudiar legal y económicamente cómo de críticos son los derechos de

autor, si es posible alcanzar un acuerdo comercial con el portal Web o qué barreras

legales podría levantar éste.


63

Para mitigar este riesgo, el primer paso será trabajar conjuntamente con

Mobincube para establecer el marco legal de la aplicación en base a su experiencia

en desarrollos previos. En el caso de que Mobincube no pueda aportar valor, sería

necesario contactar con una empresa especializada en aspectos legales y jurídicos

en aplicaciones móviles o al menos, especializada en páginas web para intentar

definir un marco por similitud.

Tras definir el marco y valorarlo económicamente, el segundo paso sería

intentar alcanzar un acuerdo con el portal Web por cesión de derechos de autor, si

fuera el caso. Para aumentar las probabilidades de éxito, en este acuerdo se ha de

presentar un estudio de cómo la aplicación repercutirá positivamente en la

fidelización de los usuarios del portal y en la captación de nuevos usuarios.

Si con las dos líneas descritas anteriormente se consigue mitigar el riesgo,

se podría considerar la aplicación como viable a nivel de mercado y a nivel

técnico. Ya con la elección de una aplicación híbrida se redujo el impacto de la

fragmentación, el otro gran riesgo de la aplicación, y los posibles costes derivados

de un cambio de diseño o de imprevistos no son relevantes frente a las grandes

oportunidades y fortalezas analizadas.

El gran crecimiento del sector y del uso de los dispositivos móviles, que

en España suman 50,6 millones de líneas; el gran número de usuarios potenciales

de la aplicación, 51.505 usuarios diarios; y un diseño desarrollado bajo una

metodología de trabajo que busca una alta aceptación por los usuarios, constituyen

la base para que la aplicación alcance un gran número de descargas.

Para finalizar y concluir si lanzar la aplicación al mercado o no, sería

necesario estudiar su viabilidad económico-financiera.

4.2. Conclusiones del desarrollo del proyecto

Conocer y profundizar el lenguaje UML ha sido, personalmente, la parte más

enriquecedora del desarrollo del proyecto. UML ofrece la posibilidad de modelar un

desarrollo completo a través de un modelado gráfico estándar entendible por cualquier

desarrollador o incluso “máquina” y que, además, es independiente tanto de la

metodología de trabajo como del lenguaje de programación. Estas cualidades lo hacen

útil para cualquier desarrollo, ya sea Web, aplicaciones, procesos de negocio, etc. y para

cualquier tamaño.

Para el uso concreto de UML en el desarrollo de aplicaciones móviles, si bien hay

numerosos autores que han propuesto una posible extensión, todavía no existe una versión

estándar que recoja las peculiaridades de las aplicaciones móviles. El gran reto en este

campo es modelar la “movilidad” del sistema.

Una de las propuestas más interesantes para ello es la que propone Michael

Decker, que resuelve el problema de la movilidad a través de un “atributo” de las

actividades del flujo de actividades, que las hará disponibles o no en función de la


64

localización del dispositivo, y a través de una serie de reglas para regular la ejecución

conjunta de actividades. A este atributo y a estas reglas las denomina “Restricciones de

localización” y “Reglas de localización”. (Decker, 2010).

Otra propuesta interesante es la que propone un grupo de investigación de la

Universita di Roma “Tor Vergata”, en dónde la movilidad se modela como un cambio en

la relación entre dos entidades móviles, en la que una de ellas actúan como “contenedor”

(Grassi, Mirandola, & Sabetta, 2004).

Como conclusión, cabe destacar que para aplicaciones móviles sencillas (como es

el caso de este proyecto) el estándar actual UML es perfectamente útil, pero para

desarrollos más complejos en los que se necesite modelar la “movilidad”, es necesario

que se estandarice una extensión. Este hecho no supone una barrera en el uso de UML,

al contrario, son numerosos los investigadores que apuestan por UML, desarrollando y

proponiendo sus extensiones al resto de la comunidad y, con seguridad, en poco tiempo

estará disponible una extensión estandarizada.

4.3. Futuras líneas de trabajo

Comprende las fases restantes hasta la disponibilidad de la aplicación para los

usuarios: el estudio económico-financiero, la fase de implantación y de testeo y la fase de

comercialización.

El estudio económico-financiero es el último estudio necesario para evaluar la

viabilidad completa de la aplicación. Para determinar la rentabilidad económica del

proyecto, primero se calcularán los cash-flow que podría generar la aplicación y se

analizarán las posibles fuentes de financiación accesibles y posteriormente se aplicarán

los métodos VAN y TIR. Aunque no es alcance de este trabajo, a continuación se definen

las líneas en términos generales para calcular la inversión inicial, los costes más

representativos y los ingresos:

Inversión inicial. Se traduce en costes de recursos humanos, en el coste de

dos portátiles y en el coste de la licencia de Mobincube. El coste de los

recursos está relacionado con la planificación de cada fase, de manera que

se ha estimado que a los 3 meses correspondientes a la elaboración de la

fase de diseño, hay que sumarle 4 más para las fases de implementación y

de testeo y 2 semanas para la fase de comercialización.

Costes más representativos. Son los costes de mantenimiento, de

versionado y de actualización de la aplicación. Estos costes son una

agrupación de todos los costes de recursos.

Ingresos. Para determinar los ingresos que puede generar la aplicación se

calcula el ingreso unitario por usuario y se multiplica por el número total

de usuarios potenciales y a lo lago de la vida útil del proyecto.


65

Para determinar el ingreso unitario, se tiene que estudiar cuál será la

opción de pago más probable para los usuarios. Es decir, se tiene que

decidir si la aplicación va a ser de pago y establecer su precio objetivo o,

si por el contrario, sería más recomendable una aplicación gratuita con

funcionalidades reducidas y ofrecer una versión de pago con todas las

funcionalidades u ofrecer una aplicación gratuita y obtener ingresos por

publicidad. Bajo esta última modalidad, Mobincube ofrece el 70% de los

ingresos por publicidad (que ellos mismos buscan) y la publicación de la

aplicación en las distintas tiendas de aplicaciones.

Durante la fase de implantación se procede a la generación del código y de la base

de datos para un correcto funcionamiento de la aplicación, así como el desarrollo del

diseño gráfico. Aquí se comprobará la posibilidad real de usar todas las llamadas APIs

diseñadas y de si es necesario adaptar alguna parte del diseño.

La fase de testeo está compuesta por tres fases para asegurar la calidad y la

aceptación de la aplicación. En la primera de ellas, se comprobará la funcionalidad de la

aplicación y su ajuste a los requisitos a través de un emulador que ofrece Mobincube. Una

vez la aplicación sea funcional y estable, se llevarán a cabo pruebas de funcionalidad en

distintos dispositivos con distintas versiones de distintos sistemas operativos, dispositivos

con distintos navegadores web predeterminados y dispositivos con distintas conexiones a

Internet con objeto de detectar no disponibilidades. Con la matriz resultante de todas estas

verificaciones, se analizará las fuentes de fragmentación para las que la aplicación no

funciona y se corregirá el diseño para conseguir su disponibilidad. La última fase consiste

en evaluar la usabilidad de la aplicación con la ayuda de los usuarios y modificar el diseño

en base a sus opiniones.

En la última fase, la fase de comercialización, la aplicación se publica en las

distintas tiendas de aplicaciones y estará disponible para los usuarios.

Bibliografía

ALEXA. (s.f.). Consultado el 27 de Noviembre de 2015, de http://www.alexa.com/

Decker, M. (2010). Modelling of Mobile Workflows with UML. International Journal

on Advances in Telecommunications, 3(12), 59-71.

Ditrendia - Digital Marketing Trends. (2015). Consultado el 27 de Noviembre de 2015,

de http://www.ditrendia.es/resumen-y-conclusiones-del-informe-mobile-en-

espana-y-en-el-mundo-2015-de-ditrendia/

El País. (6 de Marzo de 2015). Consultado el 27 de Noviembre de 2015, de

http://economia.elpais.com/economia/2015/03/06/actualidad/1425667459_7503

11.html

Erfani, M., Ali Mesbah, J., & Kruchten, P. (2013). Real Challenges in Mobile App

Development. Vancouver: University of British Columbia.

Ferré Grau, X. (2015). Interacción persona-ordenador. Madrid: CEF (udima).

Fling, B. (2009). Mobile Design and Development. Estados Unidos.

Framiñan Torres, J. M. (2008). Introducción a la Arquitectura y Desarrollo de Sistemas

de Información basados en la Web. Sevilla: Universidad de Sevilla.

Grassi, V., Mirandola, R., & Sabetta, A. (2004). A UML Profile to Model Mobile Systems.

Roma: Universita di Roma “Tor Vergata”.

I. Wasserman, A. (2010). Software Engineering Issues for Mobile Application

Development. Silicon Valley: Carnegie Mellon University.

IBM. (2012). El desarrollo de aplicaciones móviles nativas, Web o híbridas. Estados

Unidos.

K. Flora, H., Wang, X., & V. Chande, S. (2014). An Investigation into Mobile Application

Development Processes: Challenges and Best Practices. I.J. Modern Education

and Computer Science, 6, 1-9.

Kinvey. (2013). Consultado el 27 de Noviembre de 2015, de

http://www.kinvey.com/blog/2086/how-long-does-it-take-to-build-a-mobile-app

Nielsen, J. &. (2013). Usabilidad en dispositivos móviles. Madrid: Anaya.

67

Notarios y Registradores: Portal jurídico. (s.f.). Consultado el 27 de Noviembre de 2015,

de http://www.notariosyregistradores.com/web/sc/ranking-de-webs-juridicas-

espanolas-basado-en-alexa/

Noticias Jurídicas. (s.f.). Consultado el 27 de Noviembre de 2015, de

http://www.noticiasjuridicas.com

Pintos Fernández, J. (2014). Aplicación de técnicas de usabilidad y accesebilidad en el

entorno cliente. Málaga: IC editorial.

Ramírez Vique, R. (2013). Métodos para el desarrollo de aplicaciones móviles.

Universitat Oberta de Catalunya.

Sommerville, I. (2011). Ingeniería de software, Novena edición. México: Pearson.

WURFL - Mobile Device Database by ScientiaMobile. (s.f.). Consultado el 27 de

Noviembre de 2015, de http://wurfl.sourceforge.net/

diseño de la aplicación móvil “noticias...

Documents